The Story of a Simple and Dangerous OS X Kernel Bug 230
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."
Re:Age is irrelevant, resistance is futile. (Score:4, Informative)
A million monkeys with typewriters....
Re:I read (Score:5, Informative)
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).
I don't think you understood (Score:5, Informative)
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.
Re:Doesn't cause panic on 10.3.9 (Score:4, Informative)
summary (Score:5, Informative)
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.
Re:But it's not Windows! (Score:5, Informative)
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)
Citation please? The line between local and remote seems to be pretty concrete and fine to me.
Re:But it's not Windows! (Score:2, Informative)
Less vulnerabilities? Yeah, right! (Score:4, Informative)
Macs have a history of having far less vulnerabilities than Windows.
From IBM research: IBM Internet Security Systems X-Force® 2008 Trend & Risk Report [ibm.com]
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.
Re:Less vulnerabilities? Yeah, right! (Score:5, Informative)
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.
Re:But it's not Windows! (Score:5, Informative)
Re:But it's not Windows! (Score:1, Informative)
No shit, Sherlock. Macs also have a history of being used 10 times less often than Windows.
Re:Love the editing (Score:2, Informative)
Re:Hahhah... kernel bug... LOL (Score:5, Informative)
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)
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.
Re:Hahhah... kernel bug... Origins? (Score:3, Informative)
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).
Re:Still get the kernel panic on Tiger (Score:1, Informative)
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.