The Hackers Handbook — Foreword

It's easy to write a nasty worm for OS X. Here's how. First of many parts.

Get It Try It

Charlie Miller more or less laid it on the line. So did MOAB.

Worse still: many of the bugs found in January are still not patched.

There's a qualitative difference between what Charlie Miller did and what MOAB often did. Their methods are also complementary - Charlie's trick was to list open source modules in OS X along with their current versions and compare with what's found at the source - and pick on any one of the many modules Apple still haven't got around to updating.

MOAB did that too - but they also picked not on bugs per se but on design flaws. For Apple deviate in two unforgivable ways from the 'open source' they claim they embrace: they both wait a scandalously long time to apply bug patches to code - bug patches they get for free from the open source community - but they also happen upon untried and untested system 'features' that break the Unix security model.

Following is a table of MOAB bugs pertaining to Apple code along with their CVEs and their current status.

Of a total of 23 bugs (of the 30 published) that pertain specifically to Apple code only 14 are patched even today. The remaining 9 bugs, although acknowledged, are still not fixed more than half a year later.

Safe Today Unsafe Tomorrow

OS X users can today look back at their day's work and claim they were 'safe'. Today. How things go tomorrow is an uncertainty. With so many bugs unpatched - with design flaws breaking the system security model - anything may happen by tomorrow.

CVE-2007-0345

MOAB bug #15 is a particularly nasty critter. Its CVE - registration number with the MITRE Corporation - is CVE-2007-0345.

MOAB #15 aka CVE-2007-0345 - still wide open today - is a design flaw. It can easily be used by any hacker to completely compromise any OS X system. And there's no defence - Apple still haven't fixed it.

As MOAB #15 gives root privileges anything can happen - both today and tomorrow. With root privileges it's possible to:

• Install a rootkit.
• Corrupt the kernel.
• Great ghost root accounts.
• Change system startup parameters.
• Get under the 'radar' of system security checks.
• Plant startup items that further corrupt the system.
• Add input managers that further corrupt the system.
• Compromise any of the binaries in /bin, /usr/bin, /sbin, /usr/sbin or add new ones.
• Compromise the firewall to always leave backdoor ports open no matter what the system or user tries to do.
• Corrupt all user accounts or just shred and delete everything on the hard drive.

With root privileges there are no limits. Not even the sky.

MOAB #15: How It Works

MOAB #15 takes advantage of several bloopers in OS X. It takes advantage of three rather inexcusable oversights (which Apple for some unknown reason simply cannot get around to fixing even though they're eminently simple to fix) with permissions on agents in the Utilities folder.

Set UID root executables must never be writable by accounts other than root. It's rather obvious: anything with the SUID root bit that you can run will run not as you but as root. If you're allowed to modify the file you can overwrite it with anything you want and run it and become root. You break the security model.

But Unix has a safeguard here: anytime you overwrite a file the SUID and SGID bits are reset.

So merely overwriting these files won't give you what you want: Unix itself - seemingly smarter than Apple - will take away all the perks before you have a chance to enjoy them. But no worry: Apple are here to give them right back to you again.

/Library/Receipts

The /Library/Receipts folder on OS X is marked root:admin 0775. That means that both the root account and the admin accounts can modify its contents. That means that anything in /Library/Receipts you don't like can be removed and replaced with something you do like.

The contents of /Library/Receipts is used by the Disk Utility backend diskutil to 'repair permissions'. DU runs its own SUID root agent DiskManagementTool to set them 'correctly'.

But the contents of /Library/Receipts can be modified by any admin user - or program running on behalf of an admin user. And most OS X users are admin users. And once /Library/Receipts is modified it's game over, lights out, and the last person to leave Cupertino please pull the plug.

Note again that this requires no bug. It does not cause programs to crash. It's a security hole in the system..

This security hole does not exist in FreeBSD, the system Apple borrow from, or in any other Unix. Only Apple's 'Unix'.

MOAB #15 doesn't get ambitious - it's not a complex scheme. Even though any level of damage could be inflicted on /Library/Receipts there's no reason to go that far when Apple cooperate so well and already provide the flaws you need.

All MOAB #15 does is overwrite the three SUID root binaries in /Applications/Utilities with nasty code of its own - and then lets the clumsy Disk Utility do the dirty work. And none of this need be observed or detectable by the user.

What Grabs Headines

Targeted attacks - the most successful of all attacks as they most often go completely undetected - obviously don't get the attention of the media. And they don't get the attention of the platform zealots either.

'rm my Mac' went completely over the zealots' heads - in particular the head of one psycho in Wisconsin who almost got sacked for again behaving like a buffoon; and the egregious population of MacRumors who got whacked and humiliated by Oompa Loompa went straight into therapy and weeks later denied they'd even heard of it; clearly it takes a worm - a major cataclysmic outbreak - to get zealots to dirty their knickers. To get the headlines. To get Apple to clean up their act.

So whilst this article series will not provide enough code for skiddies to copy and paste and propagate it will show how a major worm outbreak on OS X is eminently possible.

There's nothing arcane about any part of this: it's all eminently straightforward coding. The only reason it hasn't happened yet is the hackers don't give a shit.

But as Charlie Miller points out, things will change rapidly as soon as there's money in propagating exploits for OS X. For as things stand right now it's far easier than writing the same exploits for Windows.

'TO BE CONTINUED'

See Also
Wooden Leg
Hacking the iPhone
'How I Hacked the iPhone'
iPhone
Alpine Dottie
Effective UID: 0
iPhone and Security
iPhone and the Media
iPhone Hack to be Patched
iPhone OS X System Architecture

Thanks to Devon at Pixel Groovy for the excellent artwork.