Slashdot Mirror
The Story of a Simple and Dangerous OS X Kernel Bug
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."
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.
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.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
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.
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.
I am TheRaven on Soylent News