MOKB-30-11-2006: Apple Airport Extreme Beacon Frame Denial of Service

Apple Airport Extreme driver fails to handle certain beacon frames, leading to an out of bounds memory access, resulting in a so-called kernel panic. Other security implications may exist, although this hasn't been verified and no details can be provided until further research is done. This issue is being coordinated with Apple, and under common agreement it's been decided to keep the details private until a fix has been made available to end-users.

• More details
  

MOKB-28-11-2006: Mac OS X shared_region_make_private_np() Memory Corruption

Mac OS X shared_region_make_private_np() system call fails to handle crafted user input, leading to an exploitable memory corruption condition. Unprivileged local users can abuse this issue in order to escalate privileges (via arbitrary code execution) or cause a denial of service.

• More details and debugging information
• Proof of concept: MOKB-28-11-2006.c

MOKB-27-11-2006: Mac OS X AppleTalk AIOCREGLOCALZN Ioctl Memory Corruption

Mac OS X AppleTalk protocol handling code is vulnerable to an exploitable memory corruption issue. This particular vulnerability is caused by failure to validate input data in the AIOCREGLOCALZN ioctl command.

• More details and debug information
• Proof of concept: MOKB-27-11-2006.c (x86)

Notes on MOKB-26-11-2006: otool affected as well

MOKB-26-11-2006 also exposes a vulnerability in the otool utility:

$ otool -f mach-o_bug_pagefault_univ_1
Fat headers
Segmentation fault

$ gdb /usr/bin/otool
GNU gdb 6.3.50-20050815 (Apple version gdb-573) (Fri Oct 20 15:50:43 GMT 2006)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-apple-darwin"...Reading symbols for shared libraries ... done

(gdb) r -d mach-o_bug_pagefault_univ_1
Starting program: /usr/bin/otool -d mach-o_bug_pagefault_univ_1
Reading symbols for shared libraries . done

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x00077000
0x00043585 in ?? ()
(gdb) bt
#0  0x00043585 in ?? ()
#1  0x00008598 in ?? ()
Previous frame inner to this frame (corrupt stack?)
(gdb) info registers
eax            0x0      0
ecx            0x0      0
edx            0x0      0
ebx            0x3ff3e  261950
esp            0xbffff850       0xbffff850
ebp            0xbffff858       0xbffff858
esi            0x76ff0  487408
edi            0x732    1842
eip            0x43585  0x43585
eflags         0x10246  66118
cs             0x17     23
ss             0x1f     31
ds             0x1f     31
es             0x1f     31
fs             0x0      0
gs             0x37     55
(gdb) x/30x 0xbffff858
0xbffff858:     0xbffff8c8      0x00040118      0x0006e008      0x40000002
0xbffff868:     0x00000002      0xbffff8cc      0x00000000      0x00000002
0xbffff878:     0xbffff898      0x8fe0e25a      0x00000000      0x00000000
0xbffff888:     0x00000000      0x00000000      0x615f676e      0x00000002
0xbffff898:     0x00007373      0x79645f5f      0xffffffff      0xffffffff
0xbffff8a8:     0xffffffff      0xbebafeca      0x00000000      0x00000000
0xbffff8b8:     0x00000000      0x0003fddf      0x00000003      0xbffffc5e
0xbffff8c8:     0xbffff988      0x0003ff25

Mac OS X users and developers, beware (and be careful) about what you do with binaries. Especially when trying to analyze some "useless malware proof of concept"...

MOKB-26-11-2006: Mac OS X Universal Binary Loading Memory Corruption

Mac OS X fails to properly handle corrupted Universal Binaries, leading to an exploitable memory corruption condition with potential risk of kernel-mode arbitrary code execution. This particular vulnerability is caused by an integer overflow in the fatfile_getarch2() function. Local unprivileged users can abuse this issue with specially crafted Mach-O 'Universal' binaries.

• More details and debugging information
• Proof of concept: MOKB-26-11-2006.bz2

MOKB-24-11-2006: Mac OS X kqueue Local Denial of Service

Inconsistent handling of kqueue and kevent interfaces in the Mac OS X kernel, allows local unprivileged users to cause a denial of service condition. This particular vulnerability can be abused by a process registering a queue and a kernel event via the kevent() call, then spawning a child via fork() and attempting to register another event for the same ("parent") queue.

• More details and debugging information
• Proof of concept: MOKB-24-11-2006.c.bz2

MOKB-23-11-2006: Mac OS X Mach-O Binary Loading Memory Corruption

Mac OS X fails to properly handle corrupted Mach-O binaries, leading to an exploitable memory corruption condition. This is triggered by execution of a Mach-O binary with a valid mach_header structure and corrupted load_command data structures. Local unprivileged users can abuse this issue.

• More details and debug information
• Proof of concept: MOKB-23-11-2006.bz2

More MOKB-20-11-2006 related news

Apparently, it isn't enough to explain these issues in the most simple possible way. There will be always someone else who doesn't bother reading, checking and, well, there will be always someone willing to say something that doesn't make sense at all.

A blog post is claiming that 'crashing a Mac with a .dmg, has been known for ages'. It doesn't stop there, it even falls in the now clueless logical fallacy that has been used over and over by Mac Zealots and other creatures of Neverland for enough time now:

conveniently ignoring the fact that this is still just a crash, not an exploit, and that not all crashes are actually exploitable anyway.

Too many things mixed there and getting screwed up. Time to stop, space cowboy. Going back to Earth, the definition of a 'crash' in kernel-land has quite a few possible meanings:

• locking issues
• infinite loops (ex. filesystem code looking for non-existent blocks)
  
• unhandled exceptions (ex. invalid memory access, ala page faults, etc)
• handled exceptions (ex. known unsupported condition, poorly written code panicking for no real reason, ala fpathconf() bug, etc).
• ...

Now define exploit in the context of a kernel-land issue. Basically exploiting a bug a in kernel-land requires some conditions to be met:

• influence memory operations (ex. land at controlled memory)
• avoid hard locks
• avoid corrupting essential spots
• change execution flow gracefully

In any case, once you have abused the vulnerable condition, you will have only one chance (normally, although there are exceptions, like modules and other interfaces that can be dynamically loaded and not necessarily get totally screwed up) to subvert the execution flow, until it goes wild and causes your so-called 'crash'. So, what happens upon successful exploitation? You're pwned, Michael Knight.

So, leaving the humorous style. Mac Zealots, please get a life. If something is well beyond your understanding capability, don't worry. Go watch TV, or the iTunes Store.

Reading documentation, debugging, checking the problem, spending hours to understand how something actually works, is obviously a tedious task. It's easier to smoke some pot and mixed hash while listening to Massive Attack and Modest Mouse.

Signed, a proud Macbook, Mac OS X and iPod (it has some indie music too, but not the brainwashing kind it seems, fortunately) user.

Alert on MOKB-20-11-2006: Being exploited in the wild?

I've been contacted by a Mac OS X user about a DMG image being distributed as a supposed 'cracked' version of some software, although it contains the 'shareware' (demonstration, time-limited) version available from the vendor website.

Without further investigation, there are no reasons to think it might be the same bug as the one published in MOKB-20-11-2006. A first look over the hexdump of the file shows that it actually contains corrupted data, yet keeping certain sections of the DMG format itself.

There's no security update from Apple right now, thus I would like to strongly recommend a higher level of caution. Don't download DMG files, don't get them off untrusted sources (ex. P2P networks) and disable the Safari feature for opening this kind of files after downloading (via Preferences -> General -> Open 'safe files' after download).

Due to time limitations, research of this issue might overlap with today's release, leading to a short delay.

MOKB-21-11-2006: Mac OS X Apple UDTO HFS+ Disk Image Denial of Service (1)

Mac OS X fails to properly handle corrupted UDTO HFS+ image structures (ex. bad sectors), leading to an exploitable denial of service condition. Although it hasn't been checked further, memory corruption is present under certain conditions (in this particular case, unlikely to allow arbitrary code execution).

• More details and debugging information
• Proof of concept: MOKB-21-11-2006.dmg.bz2 and for Safari users: MOKB-21-11-2006.dmg

MOKB-20-11-2006: Mac OS X Apple UDIF Disk Image Kernel Memory Corruption (1)

Mac OS X com.apple.AppleDiskImageController fails to properly handle corrupted DMG image structures, leading to an exploitable memory corruption condition with potential kernel-mode arbitrary code execution by unprivileged users.

• More details and debugging information
• Proof of concept: MOKB-20-11-2006.dmg.bz2 (needs decompressing), MOKB-20.dmg (direct link for proud Safari users).
  

MOKB-09-11-2006: Mac OS X fpathconf() syscall denial of service

Failure to handle unknown file types by the Mac OS X kernel (XNU) fpathconf() syscall causes a kernel panic, leading to an exploitable local denial of service by non-privileged users. The bug was fixed by FreeBSD on Tue Jun 27 23:08:36 2000 UTC (6 years, 4 months ago).

• More details
• Proof of concept

MoKB starts: MOKB-01-11-2006 - Apple Airport 802.11 Probe Response Kernel Memory Corruption

The Month of Kernel Bugs has started. The first bug is a memory corruption vulnerability found and contributed by fellow H D Moore.

The Apple Airport driver provided with Orinoco-based Airport cards (1999-2003 PowerBooks, iMacs) is vulnerable to a remote memory corruption flaw. When the driver is placed into active scanning mode, a malformed probe response frame can be used to corrupt internal kernel structures, leading to arbitrary code execution.

With all the hype and buzz about the now infamous Apple wireless device driver bugs (brought to attention at Black Hat, by Johnny Cache and David Maynor, covered up and FUD'ed by others), hopefully this will bring some light (better said, proof) about the existence of such flaws in the Airport device drivers.

The vulnerability details and proof of concept code can be found in the MOKB-01-11-2006 page.

Trick or treat? Happy Halloween.