A Month to Chocolate

A spectre of things to come?

Chocolate Day 14 February 2007 will be a year since OS X users got hit by Oompa Loompa, an OS X way of saying 'ILOVEYOU'. Could things possibly be even worse this time around? Yes they could, according to the security researchers at the Month of Apple Bugs.

'The end is nigh' proclaims the sub-header for MOAB #15 which points to another 'design flaw' in Apple's operating system: permissions on Apple's own embedded SUID root modules in /Applications allow overwrites by members of the 'admin' group - meaning just about anyone or any rogue process for that matter.

Several binaries inside the /Applications directory tree are SUID root but remain writable by users in the admin group (the first user by default in a non-server OS X installation) allowing privilege escalation. A malicious user can overwrite the binaries and perform a disk permissions repair operation via the diskutil tool, effectively setting back the default ownership and permissions (SUID root).

Which binaries are affected varies from version to version. The following command taken from the CLIX script 'leakd' can find them.

find /Applications -group 80 -perm -04020 -type f -user 0

Unfixing the Fix

Fixing the vulnerable files can prove to be a wearisome process: diskutil can continue to 'repair' these permissions back to their flawed values.

Apparently for Apple (and Unsanity) 'engineers' it's the right thing to put a binary being executed with root privileges or having the setuid bit (and owned by root) at an user writable path.

An Applied Concept

But the MOAB go further than the simple exposition of this system design flaw - and reiterate that the attack vector, Apple's own diskutil, is commonly considered an elixir by the uneducated user community and a cure for everything from sunstroke to the common cold.

At this point we have observed the use of flawed permissions and the deployment of a tool (diskutil) by Apple which opens OS X to the most simple privilege escalation issues. Its repair permissions functionality is not only flawed by design but also commonly referred as a 'solution' normally recommended by Apple's tech support to almost every 'non text book' problem reported by end users.

Its integration in the system and the presence of a vulnerable permissions 'tree' (allowing users belonging to a certain group for installing application bundles, input managers, hooking every Cocoa application, etc) opens OS X to a more sophisticated malware class.

The idea of a companion style infector is nothing new, although the idea of an infector that attempts to escalate privileges in an automated fashion is certainly innovative. The infection process would involve a permissions check, a privileges check (effective uid and group) and then the proper companion method plus a final check and execution of the diskutil tool.

If we infect a file we have write access to and it happens to be set by diskutil as root owned and setuid later, execution of that file will run the infector with root privileges, effectively compromising the whole system without requiring the root user or anyone else to get 'tricked' into executing any binary.

The infector would continue running binaries, setting new privileges over them.

In other words a self-aggrandising, self-perpetuating, self-propagating worm eating up more and more of the system as time goes on.

Another Month

And this isn't only theory.

This past weekend we started working on a proof of concept deploying this concept in pure x86 assembly. We intend to release it first to AV companies before public distribution.

The code base is mostly ready. We expect to release it soon after some testing and optimisation work.

See Also
MOAB-15-01-2007: Multiple Mac OS X Local Privilege Escalation Vulnerabilities