PDA

View Full Version : Apple patches months-old Java bugs


MacBytes
Sep 26, 2008, 08:31 AM
http://www.macbytes.com/images/bytessig.gif (http://www.macbytes.com)

Category: Mac OS X
Link: Apple patches months-old Java bugs (http://www.macbytes.com/link.php?sid=20080926093118)
Description:: none

Posted on MacBytes.com (http://www.macbytes.com)
Approved by Mudbug

pit29
Sep 26, 2008, 10:03 AM
"... could be used by attackers to execute malicious code..."

Yeah, and that's what I am reading in Apples descriptions all the time. Seems like it's frequently some buffer overflow or something.

Now, I've worked as a software engineer, but that was years ago. Could someone explain to me - not too technical, though - what that means? I am most likely wrong, but to my understanding data that "overflows the buffer" may be instructions and not data, and then (by chance?) gets executed? Sounds unlikely.

Not that I want instructions how to exploit this, rather a general idea what and how real the threat is...

Guiyon
Sep 26, 2008, 10:31 AM
Depending on where it is in the codepath and how easy it is to access, it could be very dangerous. A buffer overflow generally occurs when the developer copies a chunk of data and does not perform bounds checking. When this happens, specially crafted input could cause the application to start trampling over adjacent memory location. Usually this will just crash the application but in some cases the input can be crafted just right so that it overwrites the stack frame or a chunk of the heap and, when the code segment hits the modified code, it jumps into some newly added malicious code instead of where it was supposed to go. For an example of a heap buffer overflow would be the TIFF exploit for the iPhone 1.1.1 firmware, IIRC.

C example of a bad block of code:
char buffer[ 1024 ] = {'\0'};
getstr( buffer );
return;

In the above case, it's fairly trivial to write more than 1024 characters when getstr it called and, since there is no bound checking, it will start trampling over other, potentially live, memory locations.

"... could be used by attackers to execute malicious code..."

Yeah, and that's what I am reading in Apples descriptions all the time. Seems like it's frequently some buffer overflow or something.

Now, I've worked as a software engineer, but that was years ago. Could someone explain to me - not too technical, though - what that means? I am most likely wrong, but to my understanding data that "overflows the buffer" may be instructions and not data, and then (by chance?) gets executed? Sounds unlikely.

Not that I want instructions how to exploit this, rather a general idea what and how real the threat is...

addicted44
Sep 26, 2008, 10:35 AM
"... could be used by attackers to execute malicious code..."

Yeah, and that's what I am reading in Apples descriptions all the time. Seems like it's frequently some buffer overflow or something.


Basically, your processor cannot distinguish between data and instructions. The way a program works is by storing data and instructions in separate spaces in memory. Everytime a variable is created, a fixed amount of memory space is allocated to it. A buffer overflow attack involves sending more data than can be held in the memory space.

Normally, after every instruction is executed by a processor, it gets information about the memory address on which the next instruction to be executed is located. A buffer overflow (if not checked) may cause some of the data to appear as part of the address, making it run the wrong line of code. A malicious program might cause the buffer overflow and try to readdress the code execution to itself.

pit29
Sep 26, 2008, 11:19 AM
Usually this will just crash the application but in some cases the input can be crafted just right so that it overwrites the stack frame or a chunk of the heap and, when the code segment hits the modified code, it jumps into some newly added malicious code instead of where it was supposed to go.

A malicious program might cause the buffer overflow and try to readdress the code execution to itself.

Thanks guys, that makes things clearer to me. I know that some kind of buffer overflow was used in iPhone hacks, but never thought much about how that works. I thought that buffer overflow exploits were not that reliable to exploit. Clearly, if I had combined those thoughts I would have come to the right conclusion myself...