Rixstep
 About | ACP | Buy | Industry Watch | Learning Curve | News | Search | Test
Home » Learning Curve

Summary: Symantec's OS X Threat Landscape Document

'OS X is not immune to worms and virii. Don't kid yourself.'


Aaron Adams of Symantec's Deep Sight Threat Analyst Team published a 'threat landscape' document on OS X last November. In light of the Month of Apple Bugs it's appropriate to summarise the findings.

'Succinct information regarding the OS X threat landscape is hard to come by', writes Adams. 'Much of the information regarding OS X security and threats is blatantly wrong, overwhelmed by flame wars, and generally hard to digest. This isn't to say that researchers aren't releasing accurate and cutting edge information regarding viruses, vulnerabilities, and exploitation vectors affecting the platform. On the contrary, it seems that many of the defenders or users of OS X are unaware of their existence, don't understand them, or simply choose to ignore them.'

So Adams decided to document it.

In collating data Adams relies on the research of - amongst others - Neil Archibald, Dino Dai Zovi, HD Moore, Ilja van Sprundel, Andrew Griffiths, Christian Klein, Kevin Finisterre, David Maynor, and Jon Ellch.

'After putting all of this information together, I started analysing what features of OS X lend themselves to threats and what can be done to prevent this in the future. The document was then released to Symantec customers and is now being made available to the public.'

Download it here.

History and Overview

'Because OS X is a Unix based operating system it inherits all its built in security features such as a well designed multiuser infrastructure as well as process and file attributes', writes Adams. So far so good. But he continues.

'At the time of writing Apple have released over 100 security related updates since the initial release of OS X. Vulnerabilities discovered in Apple software have fallen into the typical range of categories including local privilege escalation, client side code execution, and remote code execution.'

Local Vulnerabilities

All the vulnerabilities listed here have been fixed.

Directory Services Privilege Escalation passwd creates temporary files in an insecure manner.
Core Foundation Local Buffer Overflow Buffer overflow in CF can result in arbitrary code execution with elevated privileges.
Local Arbitrary File Modification Insecure file handling in the malloc library for SUID applications.

Remote Vulnerabilities

All the vulnerabilities listed here have been fixed.

OS X Server Remote Buffer Overflow Requests on port 660 and 2056 bytes long will crash the administration service.
AppleFileServer Remote Buffer Overflow A malformed 'LoginExt' packet can allow an attacker to gain unauthorised access.
AppleFileServer Remote Integer Overflow Failure to properly handle signed integers when copying data to process buffers.
Bluetooth Directory Traversal Input not sufficiently sanitised; attackers can access unauthorised resources.

'The above should show OS X is in no way immune to or less likely to be affected by critical remote vulnerabilities than other operating systems', suggests Adams.

'While this is by no means an exhaustive list and is limited to software specific to OS X, it is clear that vulnerabilities that could facilitate worm propagation have been discovered and in some cases exploited.'

'All of the vulnerabilities listed above have been patched by Apple.'

At time of writing (of this document) SecurityFocus record 181 advisories for OS X, 875 for Windows, 124 for OpenBSD, 917 for Debian, 360 for Fedora, and 390 for SuSE.

Design Weaknesses

Several articles cited in Adams' paper show how trivially BSD security can be circumvented through Mach. Neil Archibald has one of many such papers on the subject.

Default Services and Firewall Policies

As Jay Beale has already demonstrated, getting an OS X firewall to do one's bidding is not always easy - and OS X doesn't tell you when it's cheating either. Ports are left open despite the user being told they're closed. And so forth.

Several issues with mDNSResponder point to there having been egregious holes despite Apple never saying a word.

n = recvfrom(g_sUDP, buf, sizeof(buf), 0, // ### !!!Buffer overflow!!!
    // Should be sizeof(buf) - 1 to allow for 'buf[n] = '\0'; below !!!
            (struct sockaddr *) &recvaddr, &recvaddrlen);

'A remotely accessible default service that is accessible despite disabling UDP via the firewall - one that has had a history of security vulnerabilities - poses a fairly high security risk to users', concludes Adams.

To make matters worse, there's a new daemon on the block: serialnumberd. And its job is to detect unauthorised licences. To do this it has to receive connections on UDP port 626.

So even if a user specifically closes UDP 626, serialnumberd opens it again - without the user being any the wiser.

Zero Days

There have been many hints - from the researchers cited above and others - of zero day exploits ready for OS X.

Malicious Code

To date there has been little malicious code for OS X in the wild. Amongst the most memorable are Oompa Loompa, InqTana and descendants, Opener, and MP3Concept.

InqTanaObjective-C method swizzling, input managers, DYLD_INSERT_LIBRARIES.
MP3ConceptCreator code/file type trickery, social engineering.
OompaObjective-C method swizzling, input managers, resource fork infection.
OpenerStartup items root SUM security hole.

Both InqTana and MP3Concept were POCs; both Oompa and Opener were found in the wild.

Apropos InqTana author Kevin Finisterre wrote an extensive paper 'InqTana Through the Eyes of Dr Frankenstein' cited below.

DYLD_INSERT_LIBRARIES

One of the most frightening things Finisterre discovered was a legacy gaffe from NeXTSTEP. The following saved as ~/.MacOSX/environment.plist allows a rogue input manager to run in every process.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>DYLD_INSERT_LIBRARIES</key>
    <string><PATH TO YOUR BAD BAD DYLIB></string>
</dict>
</plist>

The shell script Opener logged keystrokes, created ghost accounts, opened the target for remote access, disabled security software and auto updates, cracked passwords, and stored logged information and cracked passwords in a hidden directory.

Opener is most noteworthy for exposing the 'startup items hole' on OS X: with no authentication whatsoever any admin user could copy code into /Library/StartupItems to be run not only as root but as root in single user mode on next startup.

The author had repeatedly been in contact with Apple about the hole but been dismissed each time. Apple finally plugged the hole silently with the release of Tiger 29 April 2005 - and without ever mentioning the fact that the possibly biggest hole ever in personal computing had ever existed.

An OS X Virus!

OS X even has its own virus. It doesn't have hundreds of thousands like Windows but it has at least one. It's called 'Macarena'.

Found in October 2006, Macarena only affects x86 images. It uses a previously known entry point hooking technique and a cavity infection technique to seize control of applications as they're loaded. It slaps another 528 bytes of code onto targeted binaries.

The version found in the wild would seem to be deliberately innocuous.

Heap Overflows

Neil Archibald ('nemo') wrote an excellent paper on the subject of exploiting heap overflows which prompted Apple to issue a fix for an integer wrapping bug soon after publication.

Rootkits

To date there have been three known rootkits for OS X.

WeaponX was written by Neil Archibald ('nemo') in 2004. The source code was freely available. The currently available version does not work with 10.4 because of the remapping of the KPIs. A new version for 10.4 is reportedly in the works.

WeaponX has a small set of features to effect local privilege escalation, hide the presence of users and open ports, and hide its own presence in the kernel.

[*] setuid(1337) will leave user with uid=0.
[*] Hides itself from kextstat.
[*] Give a chosen process uid=0 with signal 1337.
[*] Hides a given port from netstat.
[*] Hides a user from w and who.

The new version will avoid use of kernel modules and access kernel memory directly through use of Mach system calls.

OSXRK was written in 2004 by 'g@pple'. Its code has also been available. OSXRK is a 'userland' rootkit functioning as a backdoor, a system log cleaner, a password cracker, and a sniffer. OSXRK may not fool a seasoned pro but it's more than sufficient to fool ordinary users.

Togroot is the simplest of the three and the only one with no source code available. It too was written in 2004. It runs as a kernel extension. No new versions have been found.

/givemeroot
su

Defence

The most important defence against security threats according to Aaron Adams? (Hint: it's not Symantec AV.) User education.

'A concerning trend amongst OS X users is relatively carefree downloading of applications, disk images, desktop widgets, and other potentially malicious data.'

'This threat is compounded by an unfortunate perception of immunity to malicious code and a general lack of understanding of basic computer security.'

Future Threats, Future Defences

'With the release of OS X on the x86 platform the operating system has become more accessible to researchers', notes Adams. It can now be run on a variety of emulators and virtual machines that support the 64-bit format.'

'At time of writing unauthorised OS X install disks and images are available that allow it to be run with VMWare. This new development will likely increase research into the OS since access to the platform no longer requires the purchase of special hardware.'

Neil Archibald already gave a talk 'Infecting the Mach-O Object Format' on trivial concatenation viruses, resource fork infectors, traditional entry point hooking infection, kernel infection, Objective-C infection, multiple architecture ('fat') binary infection, and other topics.

Preventive Measures

According to Adams older Darwin builds were littered with integer related bugs and more recent builds show many of these bugs have been found and removed. Source code audits are still crucial. And as complexity of a system increases, so do the dangers for new holes and concomitant exploits.

Canary values are already in use on several platforms including Windows 2003, Windows XP SP2, and OpenBSD and are available with the GCC but as yet are only in limited use by Apple.

The GCC -fstack-protector-all flag can be used to store special 'canary' values around sensitive values such as return addresses and saved base pointers. When the caller notices these values have been corrupted it can then exit the program.

Secure heap implementation is becoming available on Linux (ptmalloc2) and OpenBSD (mmap) but not as yet on OS X.

Address space layout randomisation can be used to thwart exploits with static address references. ASLR takes advantage of the relocatability of shared libraries.

A related issue, notes Adams, is the fact that Apple, like Microsoft and other companies, distribute their OS as pre-compiled binaries, making it all the easier for attackers to continue using static address references.

Non-executable memory wasn't supported by 32-bit Intel but was available for the PowerPC. Yet Apple never used the technique.

Apple now use it to a limited extent with their Core Duo hardware which although lacking native support has access to 'EM64T' 64-bit extensions compatible with AMD64. This includes support for the XD bit (AMD64 NX bit). So far Apple only use this with stack memory.

However Kevin Finisterre has already shown how this feature can be trivially circumvented.

Conclusions

OS X is not widely targeted, notes Adams, but goes on to explain.

'This is likely because the target OS has not been as popular as other systems and because the underlying hardware architecture is unfamiliar. With the recent move to Intel x86 processors however Apple users can almost assuredly be considered at a higher risk of attack than ever before. For a long time the x86 platform has been the most widely exploited and therefore most attackers and researchers specialise in programming for that particular assembly language.'

'The move to x86 architecture will make converting already built payloads and other programs that target x86 much easier for attackers to aim at OS X.'

References
SourceForge: HTE
Immunix: StackGuard
SureSEC: Securing the Source
Bastille Linux: Bastille on OS X
Archibald: Infecting the Mach-O Object Format
FelineMenace: Resource Fork Infection POC (2005)
Kevin Finisterre: Non eXecutable Stack Lovin on OS X 86
IBM: GCC extension for protecting applications from stack-smashing attacks
FelineMenace: Mach-O Loading Denial of Service Vulnerability
SecurityFocus: semop() System Call POC
SecurityFocus: AirPort Driver Remote Kernel Level DOS POC
SecurityFocus: Samba 'call_trans2open' Remote Buffer Overflow Vulnerability
SecurityFocus: AppleFileServer Pathname Buffer Overflow Exploit
SecurityFocus: Archive Metadata Command Execution
Digital Munition: launchd syslog Format String Privilege Escalation Exploit
SecurityFocus: Adobe Version Cue Privilege Escalation Exploit
SecurityFocus: passwd Utility File Creation and Corruption
SecurityFocus: CF_CHARSET_PATH Environment Variable Overflow Exploit
SureSEC: Black Hat Europe 2005
Archibald: OS X Heap Exploitation Techniques
B-r00t: PPC Shellcode Assembly
Symantec: OSX.Macarena
Kevin Finisterre: Bluetooth Hacking Revisited
Kevin Finisterre: InqTana Through the Eyes of Dr Frankenstein
Symantec: MP3Concept
Jay Beale: Discovering OS X Weaknesses
FelineMenace: Breaking OS X
Uninformed: Abusing Mach on OS X
Symantec: OS X Threat Landscape Document


Thanks to Nick, Yan, and all the rest at the CLIX Exchange for harping about this for so long.

About | ACP | Buy | Industry Watch | Learning Curve | News | Products | Search | Substack
Copyright © Rixstep. All rights reserved.