That is, unless the virus interacts with a root process which doesn't truncate input properly...
Yup. The UNIX worm lives on. The C89 committee should have gotten rid of gets() while they had the chance to*.
However, given that it's not at all easy to find buffer overruns relative to the huge neon signs pointing at gaping holes in Windows, and given that it's generally very easy to fix them, this is a much smaller problem. It's a problem, for sure, but not a big one. Also, if the only way to get to the root process is by having the user deliberately execute an application and then type in their administrator password, it's something of a non-issue. The UNIX worm exploited a really obvious buffer overrun in the password field at login.
The last really serious hole in Apple's security was in Software Update, where there was a way for a third party to spoof Apple's update server. Apple squashed that one pretty quickly too.
* For non-programmers: In C, you have to reserve a space of a fixed size, called a buffer, in order to store data like strings and lists of numbers. You write to this buffer by starting at the address in memory of the beginning and adding an offset of zero or more depending on where in the buffer you want to write the data - and, for performance reasons, C does not check to make sure this offset is within the buffer! So you can allocate, say, 9 characters to store a password (UNIX passwords are historically 8 characters long, and C requires a terminating nul character), and you can write a loop that reads in 15 characters and writes them to the 9 characters you allocated... and which writes the last 6 characters into whatever memory happens to be nearby, and C won't even blink. For that matter, you can write to memory you haven't reserved at all and C won't blink, although the resulting code might trip any memory protection the OS maintains.
Now, to add insult to injury, C included a function called gets(), for "get string", which would read in a string of arbitrary length (that the user had typed in, usually) and write it into a buffer - without checking that the buffer was big enough, or even that there was a buffer there! Older UNIXen used gets() to retrieve passwords at login, so there was this huge gaping vulnerability where a cracker could login except with an 8 character password followed by a string of executable code, which gets() would dutifully write into the memory beyond that allocated for the password. Then all the worm had to do was see to it that the OS got a pointer to that code, and it would execute.
Needless to say, gets() has been purged from UNIX code, and from most C code as well. But it's still part of C, and any time you hear about a buffer overrun (or underrun - C doesn't prevent you from writing before the beginning of a buffer either!) the problem is essentially that some bit of code made the same mistake that gets() makes, not checking to make sure that there's been enough room reserved to store the data it's handling.
Also, if the only way to get to the root process is by having the user deliberately execute an application and then type in their administrator password, it's something of a non-issue.
True... Microsoft has made some rather dubious decisions with regards to this topic. Most users with their own desktop at home or in the office tend to use an administrative account as their normal login. With OS X, this is relatively benign as su-esque things still require a password. Yet, with WinXP, this isn't true, once you?ve logged in, programs running under your normal (admin) login can stomp all over just about anything.
Also, windows has placed much more in the kernel space than OS X. It is a tradeoff in which MS chose to accelerate much of the windowing system by sacrificing security.
Comments
Originally posted by dfiler
That is, unless the virus interacts with a root process which doesn't truncate input properly...
Yup. The UNIX worm lives on. The C89 committee should have gotten rid of gets() while they had the chance to*.
However, given that it's not at all easy to find buffer overruns relative to the huge neon signs pointing at gaping holes in Windows, and given that it's generally very easy to fix them, this is a much smaller problem. It's a problem, for sure, but not a big one. Also, if the only way to get to the root process is by having the user deliberately execute an application and then type in their administrator password, it's something of a non-issue. The UNIX worm exploited a really obvious buffer overrun in the password field at login.
The last really serious hole in Apple's security was in Software Update, where there was a way for a third party to spoof Apple's update server. Apple squashed that one pretty quickly too.
* For non-programmers: In C, you have to reserve a space of a fixed size, called a buffer, in order to store data like strings and lists of numbers. You write to this buffer by starting at the address in memory of the beginning and adding an offset of zero or more depending on where in the buffer you want to write the data - and, for performance reasons, C does not check to make sure this offset is within the buffer! So you can allocate, say, 9 characters to store a password (UNIX passwords are historically 8 characters long, and C requires a terminating nul character), and you can write a loop that reads in 15 characters and writes them to the 9 characters you allocated... and which writes the last 6 characters into whatever memory happens to be nearby, and C won't even blink. For that matter, you can write to memory you haven't reserved at all and C won't blink, although the resulting code might trip any memory protection the OS maintains.
Now, to add insult to injury, C included a function called gets(), for "get string", which would read in a string of arbitrary length (that the user had typed in, usually) and write it into a buffer - without checking that the buffer was big enough, or even that there was a buffer there! Older UNIXen used gets() to retrieve passwords at login, so there was this huge gaping vulnerability where a cracker could login except with an 8 character password followed by a string of executable code, which gets() would dutifully write into the memory beyond that allocated for the password. Then all the worm had to do was see to it that the OS got a pointer to that code, and it would execute.
Needless to say, gets() has been purged from UNIX code, and from most C code as well. But it's still part of C, and any time you hear about a buffer overrun (or underrun - C doesn't prevent you from writing before the beginning of a buffer either!) the problem is essentially that some bit of code made the same mistake that gets() makes, not checking to make sure that there's been enough room reserved to store the data it's handling.
Originally posted by Amorph
Also, if the only way to get to the root process is by having the user deliberately execute an application and then type in their administrator password, it's something of a non-issue.
True... Microsoft has made some rather dubious decisions with regards to this topic. Most users with their own desktop at home or in the office tend to use an administrative account as their normal login. With OS X, this is relatively benign as su-esque things still require a password. Yet, with WinXP, this isn't true, once you?ve logged in, programs running under your normal (admin) login can stomp all over just about anything.
Also, windows has placed much more in the kernel space than OS X. It is a tradeoff in which MS chose to accelerate much of the windowing system by sacrificing security.