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."
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....
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).
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.
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.
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.
Citation please? The line between local and remote seems to be pretty concrete and fine to me.
"linux is just DOS with a UNIX like syntax" -- Galactic Dominator (944134)
Yes because even we manage to fix our kernel bugs faster than 2+ years
Me failed English...
FreeBSD over Linux. If my comments seem odd, this may explain...
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.
Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
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.
I am TheRaven on Soylent News
No shit, Sherlock. Macs also have a history of being used 10 times less often than Windows.
"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.)
#naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
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
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.
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).
I am TheRaven on Soylent News
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.