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.

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.

2009 marks the 12th year that InformationWeek will be monitoring changes in security practices through our annual research survey. Find out more and take part.