Forgot your password?
Bug OS X Security

The Story of a Simple and Dangerous OS X Kernel Bug 230

Posted by timothy
from the chink-in-the-armor dept.
RazvanM writes "At the beginning of this month the Mac OS X 10.5.8 closed a kernel vulnerability that lasted more than 4 years, covering all the 10.4 and (almost all) 10.5 Mac OS X releases. This article presents some twitter-size programs that trigger the bug. The mechanics are so simple that can be easily explained to anybody possessing some minimal knowledge about how operating systems works. Beside being a good educational example this is also a scary proof that very mature code can still be vulnerable in rather unsophisticated ways."
This discussion has been archived. No new comments can be posted.

The Story of a Simple and Dangerous OS X Kernel Bug

Comments Filter:
  • by Idiot with a gun (1081749) on Sunday August 30, 2009 @01:01AM (#29249467)
    I believe the implied meaning of this is "in the absence of exhaustive security analysis, a code's age/maturity is one of the better indicators of its security". While I'm not particularly sold on this notion myself, it does bear a lot of semblance to the idea that code can be proven "secure" if it stands after a multitude of random attacks, which is basically one of the tenets of OSS.

    A million monkeys with typewriters....
  • Re:I read (Score:5, Informative)

    by emurphy42 (631808) on Sunday August 30, 2009 @01:25AM (#29249597) Homepage
    The relevant part is:

    The problem is the data in the buggy case is whatever we give as a third parameter in the fcntl code. Considering that the 8 bytes are controlled by the user it means he can write that amount of information anywhere in the kernel memory!

    followed by an example of actually doing it and proving that it worked (not a particularly malicious example, but it seems enough proof of concept to me).

  • by pathological liar (659969) on Sunday August 30, 2009 @01:32AM (#29249627)

    What are you, a Linux kernel dev? ;)

    The bug lets you write arbitrary, user-controlled bytes into kernel space. The first thing that comes to mind is that you could change the current process' priv structure in memory. Now you're root. Or why not use it to hook syscalls, or do really whatever you want? You're in ring0, go nuts.

    It's far more than just a DoS.

  • by noidentity (188756) on Sunday August 30, 2009 @01:32AM (#29249629)
    I did read the blog posting, and it says "The oldest kernel I was able to test the problem was Darwin 8.0.1 which corresponds to Mac OS X 10.4 'Tiger'." I figured I'd post a result on an earlier one, so shove it.
  • summary (Score:5, Informative)

    by Trepidity (597) <> on Sunday August 30, 2009 @01:56AM (#29249699)

    Despite its relative obviousness, it took me a bit of reading there to figure out what the cause of the bug was, since I was rusty on my Unix system calls, so here's a short summary.

    ioctl(2) is essentially a way of specifying system calls for drivers without actually making a system call API, so drivers can register their own calls in a more decentralized way. A call to ioctl(fd, cmd, args, ...) on a special/device file 'fd' gets routed to the driver that owns 'fd', which handles the command. The arguments might be values, or might be pointers to locations in which to return data.

    fcntl(2) provides a way to perform operations on open (normal) files, like locking/unlocking them. It has the same parameters as ioctl(), except that there's always a single integer argument.

    One way of implementing fcntl is essentially like ioctl -- find who owns the fd, and pass the cmd along to the relevant driver. But, Apple's code did this even for the operations on special devices normally manipulated via ioctl, so you could basically do an ioctl via fcntl. But, this bypasses some of the arg-checking that ioctl does, since fcntl always has one integer argument. So an easy exploit arises: call an ioctl that normally takes one pointer argument to assign something to. ioctl would normally check that the pointer is valid (something the caller is allowed to write to) before writing to it in kernel mode. But you can pass in any memory location at all as an integer via fcntl's argument. Voila, you get data written to arbitrary locations in memory. As an added bonus, some calls let you manipulate what data gets written--- the example exploit uses a "get terminal size" ioctl, so you can vary what gets written by changing your terminal size.

  • by tagno25 (1518033) on Sunday August 30, 2009 @02:32AM (#29249853)

    Same could be said for Linux! Right? Right? Being open source makes it invulnerable?

    No, it being open source means that the vulnerabilities can be fixed quicker than 2+ years.

    Linux has had more known vulnerabilities than Windows, but that is because people can see the source and find the vulnerabilities. It has also had more fixed vulnerabilities and currently has less valid vulnerabilities than Windows.

  • Re:I read (Score:3, Informative)

    by Sir_Lewk (967686) <> on Sunday August 30, 2009 @02:40AM (#29249865)

    local and remote exploits and the line between them are being blurred every day

    Citation please? The line between local and remote seems to be pretty concrete and fine to me.

  • by benjymouse (756774) on Sunday August 30, 2009 @04:12AM (#29250165)

    Macs have a history of having far less vulnerabilities than Windows.

    From IBM research: IBM Internet Security Systems X-Force® 2008 Trend & Risk Report []

    Look under "most vulnerable operating system". Yes, right at the top, for several years going sits OS X. It actually consistently experiences 3 times the number of vulnerabilities compared to Vista.

    You can also do some secunia digging yourself. It shows the same tendency even in the raw data.

    OS X may be less exploited but it has far more vulnerabilities. On top of that OS X lacks many of the anti-exploit mechanisms found in both common Linux distros and in Windows Vista.

    Vulnerabilities does not have much to do with exploits. A single vulnerability may leads to several independant exploits. Many vulnerabilities will pass unexploited. The difference is incentive. And if pwn2own has showed us anything it certainly confirms this. Macs have consistently been the first to fall, literally within seconds.

  • by TheRaven64 (641858) on Sunday August 30, 2009 @07:26AM (#29250751) Journal
    While I agree that there are a lot more security holes in OS X than there ought to be (and you only need one to win pwn2own), I seem to recall reading that study when it came out and being less than impressed with their methodology. They did not weight the types of vulnerability in a sensible way, and they included a number of bugs in components of OS X that have no equivalent bundled with Windows (and several of the most vulnerable ones are not enabled by default), but doesn't include exploit counts for Windows equivalents.

    On top of that OS X lacks many of the anti-exploit mechanisms found in both common Linux distros and in Windows Vista.

    Not sure about that. OS X has a very advanced sandboxing system, and has since OS X 10.5. This is why the mDNSResponder bug last year was a remote root hole on Linux, Windows, and OS X 10.4 and a DoS on OS X 10.5 and above.

  • by TheRaven64 (641858) on Sunday August 30, 2009 @07:30AM (#29250767) Journal
    This bug was in one of the open source parts of the XNU kernel. A third party did find the flaw and, once it was demonstrated to be dangerous, Apple released a fix quickly. I object slightly to the fact that they ignored it for about a year when they thought it was 'only' able to crash the kernel, but maybe they had more pressing issues that they needed to fix. Given that the source is available, under a license which permits both recompilation and distribution of modified versions, this isn't an open versus closed debate, it's a question of how many people bother to look and fix bugs. Last numbers I saw said there were 78 people actively working on the Linux kernel, and not all of these full-time; I expect Apple devotes a similar number of man-hours to XNU, but divided among fewer people.
  • by Anonymous Coward on Sunday August 30, 2009 @07:42AM (#29250817)

    No shit, Sherlock. Macs also have a history of being used 10 times less often than Windows.

  • Re:Love the editing (Score:2, Informative)

    by Megane (129182) on Sunday August 30, 2009 @07:46AM (#29250841) Homepage
    "Mechanics" is plural, and yet you want to use "it" as a pronoun for a plural word? Grammar really has gone to crap. (Also, how operating systems work, another case of mis-matched plurality.)
  • by TheRaven64 (641858) on Sunday August 30, 2009 @07:47AM (#29250843) Journal

    No, XNU plus userland is Darwin. Darwin does not contain a number of proprietary drivers including, unfortunately, the entire sound stack.

    For GNU types, XNU is equivalent to Linux, Darwin is equivalent to GNU/Linux, OS X is equivalent to Ubuntu (in terms of bundling nomenclature, I make no claims about feature equivalence). Darwin includes the libc, the loader, the init system (Launhcd), the toolchain and so on. XNU is just the kernel, which incorporates a Mach microkernel used as a hardware-abstraction layer and handles the VM subsystem and thread creation, a BSD subsystem which handles providing a POSIX interface to the Mach stuff and all of the other OS services, and IOKit drivers, which provide access to devices.

  • Re:I read (Score:3, Informative)

    by chefmonkey (140671) on Sunday August 30, 2009 @11:56AM (#29252405)

    Am I missing something?

    Yes, you are.

    The exploit allows users to choose an arbitrary location in memory -- including kernel space -- and write 8 bytes to it at a time. The 8 bytes are chosen by the terminal program attached to the TTY that the system call is made on. So, if a local program attaches to a TTY in the same way that a terminal does, and then makes this system call, it can load executable code into the kernel (or anywhere else, for that matter).

    In other words, it makes it ridiculously simple to run any code you want as root.

  • by TheRaven64 (641858) on Sunday August 30, 2009 @12:40PM (#29252837) Journal
    Without looking at the code, I can't tell you for certain, but looking at the traces that were in TFA it looks like the code is part of the bottom of the BSD stack responsible for handing over control to the device driver layer. This is almost certainly Apple code, because it contains interfaces to Mach and IOKit.

    Given that the bug is in tty handling, I wouldn't be surprised if some of this code dates back to 4BSD or even earlier (take a look at the change log for the firs OpenBSD release to get an idea of how buggy the original BSD releases were).

  • by Anonymous Coward on Sunday August 30, 2009 @01:45PM (#29253395)

    It appears so. The Apple doc on Security Update 2009-003 only shows this as 'affecting' 10.5. Meaning, they didn't fix it in 10.4. I guess this is standard Apple practice when they release a newer toy than the previous one. That would mean 10.5 may now be in this category of abandoned toy now that Apple Toy 10.6 is out.

panic: can't find /