Linked by Thom Holwerda on Tue 22nd May 2012 23:26 UTC
Internet & Networking "Just over two months ago, Chrome sponsored the Pwnium browser hacking competition. We had two fantastic submissions, and successfully blocked both exploits within 24 hours of their unveiling. Today, we'd like to offer an inside look into the exploit submitted by Pinkie Pie." A work of pure art, this. Also, this is not the same person as the other PinkiePie. Also also, you didn't think I'd let a story with a headline like this go by unnoticed, did you?
Thread beginning with comment 519105
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[3]: Comment by Radio
by moondevil on Wed 23rd May 2012 09:32 UTC in reply to "RE[2]: Comment by Radio"
moondevil
Member since:
2005-07-08

Did you actually read the functions? It is a calculation logic error. There is no language alive to prevent logic errors. The logic error results in an invalid buffer access for a GPU related task. No "sane" language has yet been extended to use GPUs that do no rely on creating buffers directly at some point in its execution.


Yes I've read the functions, ComputeMaxResults() and ComputeSize(),
are the standard way to manipulate blocks of memory/arrays in C and related to the way arrays decay into pointers.


You do understand that were a managed language required to access the GPU, it would also need to do manual memory management undercovers, don't you?


Safe programming languages != GC != Managed.

Ada, Modula-2, Delphi, Turbo Pascal are safe programming languages with manual memory management, compiling nicely to native code as well, just as an example.

Reply Parent Score: 2

RE[4]: Comment by Radio
by kwan_e on Wed 23rd May 2012 09:36 in reply to "RE[3]: Comment by Radio"
kwan_e Member since:
2007-02-18

Ada, Modula-2, Delphi, Turbo Pascal are safe programming languages with manual memory management, compiling nicely to native code as well, just as an example.


And do they prevent you from making the LOGIC ERROR that was explained about the functions?

Reply Parent Score: 2

RE[5]: Comment by Radio
by moondevil on Wed 23rd May 2012 11:09 in reply to "RE[4]: Comment by Radio"
moondevil Member since:
2005-07-08

And do they prevent you from making the LOGIC ERROR that was explained about the functions?


YES! Because the LOGIC ERROR is about a MEMORY ACCESS ALGORITHM known to ANY C PROGRAMMER.

Reply Parent Score: 3

RE[4]: Comment by Radio
by looncraz on Wed 23rd May 2012 17:02 in reply to "RE[3]: Comment by Radio"
looncraz Member since:
2005-07-24

**ALL** languages talk to the hardware the same way!

Memory pointers are a hardware feature. They just happen to be 'exposed' in c/++. I can use assembly to fool any programming written in any language that I am friendly and of the same breed and interject myself using hardware features.

Security like you are speaking would require a massive hardware change where memory is addressed in locked relative-memory segments. That is every process can create restricted areas of memory which can only be accessed by a compile-time validated code-path - something a few steps beyond nX-bits.

Even then, you would only need to find a way to inject yourself into that code-path by altering the binary... but that would be easier to catch and prevent. You would then need to rely on OS/hardware bugs... but you would still be able to get 'in' in some manner...nothing is safe beyond not permitting execution at all...

Which language was used simply doesn't mean squat. A program written in Delphi still debases itself to the same approximate code which was written in c. I'm still using movl %eax, %ecx, call, jmp, etc...

--The loon

Edited 2012-05-23 17:02 UTC

Reply Parent Score: 2