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 519101
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[2]: Comment by Radio
by kwan_e on Wed 23rd May 2012 08:14 UTC in reply to "RE: Comment by Radio"
kwan_e
Member since:
2007-02-18

If ComputeMaxResults() was done in a more sane language, this exploit wouldn't have been possible, without doing some Assembly code rewriting.


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.

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?

Reply Parent Score: 6

RE[3]: Comment by Radio
by moondevil on Wed 23rd May 2012 09:32 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[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

RE[3]: Comment by Radio
by panzi on Wed 23rd May 2012 20:39 in reply to "RE[2]: Comment by Radio"
panzi Member since:
2006-01-22

You say there is no known language where this calculation would return the right result? Obviously you don't know Python or Ruby. These language have variable length integers which means that you never have a integer overflow/underflow.

Yes, the result is then a negative number. But given the definition of the function and the parameters the result is "correct". And in Ruby/Python you don't have any buffers through which you can access arbitrary memory anyway.

Reply Parent Score: 2

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

You say there is no known language where this calculation would return the right result? Obviously you don't know Python or Ruby. These language have variable length integers which means that you never have a integer overflow/underflow.


I've programmed in Python. I love Python. How would you suggest Python be able to directly instruct the GPU? I'll give you a hint: you write the extension in C.

This is the cause of my earlier lament. People like you treat it as though languages like Python and Ruby magically spawn out of nowhere without having anything to do with C.

Yes, the result is then a negative number. But given the definition of the function and the parameters the result is "correct".


But given the PURPOSE of the function, the "correct" answer is wrong. And you'll end up with the same problem of incorrectly addressing the buffers contents.

So it is a LOGIC error. The formula is WRONG. Languages cannot fix wrong formulae, which is the heart of the problem with the function.

And in Ruby/Python you don't have any buffers through which you can access arbitrary memory anyway.


Unless you write an extension in C, which you pretty much have to do if you want it to talk to the GPU.

This is why one of the earlier commenters was right. This is about the GPU. Not the language.

Reply Parent Score: 3