ReMASTering Applications by Obfuscating during Compilation

In this post, we discuss the creation of a novel software obfuscation toolkit, MAST, implemented in the LLVM compiler and suitable for denying program understanding to even the most well-resourced adversary. Our implementation is inspired by effective obfuscation techniques used by nation-state malware and techniques discussed in academic literature. MAST enables software developers to protect applications with technology developed for offense.

MAST is a product of Cyber Fast Track, and we would like to thank Mudge and DARPA for funding our work. This project would not have been possible without their support. MAST is now a commercial product offering of Trail of Bits and companies interested in licensing it for their own use should contact


There are a lot of risks in releasing software these days. Once upon a time, reverse engineering software presented a challenge best solved by experienced and skilled reverse engineers at great expense. It was worthwhile for reasonably well-funded groups to reverse engineer and recreate proprietary technology or for clever but bored people to generate party tricks. Despite the latter type of people causing all kinds of mild internet havoc, reverse engineering wasn’t widely considered a serious threat until relatively recently.

Over time, however, the stakes have risen; criminal entities, corporations, even nation-states have become extremely interested in software vulnerabilities. These entities seek to either defend their own network, applications, users, or to attack someone else’s. Historically, software obfuscation was a concern of the “good guys”, who were interested in protecting their intellectual property. It wasn’t long before malicious entities began obfuscating their own tools to protect captured tools from analysis.

A recent example of successful obfuscation is that used by the authors of the Gauss malware; several days after discovering the malware, Kaspersky Lab, a respected malware analysis lab and antivirus company, posted a public plea for assistance in decrypting a portion of the code. That even a company of professionals had trouble enough to ask for outside help is telling: obfuscation can be very effective. Professional researchers have been unable to deobfuscate Gauss to this day.


With all of this in mind, we were inspired by Gauss to create a software protection system that leapfrogs available analysis technology. Could we repurpose techniques from software exploitation and malware obfuscation into a state-of-the-art software protection system? Our team is quite familiar with publicly available tools for assisting in reverse engineering tasks and considered how to significantly reduce their efficacy, if not deny it altogether.

Software developers seek to protect varying classes of information within a program. Our system must account for each with equal levels of protection to satisfy these potential use cases:

  • Algorithms: adversary knowledge of proprietary technology
  • Data: knowledge of proprietary data (the company’s or the user’s)
  • Vulnerabilities: knowledge of vulnerabilities within the program

In order for the software protection system to be useful to developers, it must be:

  • Easy to use: the obfuscation should be transparent to our development process, not alter or interfere with it. No annotations should be necessary, though we may want them in certain cases.
  • Cross-platform: the obfuscation should apply uniformly to all applications and frameworks that we use, including mobile or embedded devices that may run on different processor architectures.
  • Protect against state-of-the-art analysis: our obfuscation should leapfrog available static analysis tools and techniques and require novel research advances to see through.

Finally, we assume an attacker will have access to the static program image; many software applications are going to be directly accessible to a dedicated attacker. For example, an attacker interested in a mobile application, anti-virus signatures, or software patches will have the static program image to study.

Our Approach

We decided to focus primarily on preventing static analysis; in this day and age there are a lot of tools that can be run statically over application binaries to gain information with less work and time required by attackers, and many attackers are proficient in generating their own situation-specific tools. Static tools can often very quickly be run over large amounts of code, without necessitating the attacker having an environment in which to execute the target binary.

We decided on a group of techniques that compose together, comprising opaque predicate insertion, code diffusion, and – because our original scope was iOS applications – mangling of Objective-C symbols. These make the protected application impossible to understand without environmental data, impossible to analyze with current static analysis tools due to alias analysis limitations, and deny the effectiveness of breakpoints, method name retrieval scripts, and other common reversing techniques. In combination, these techniques attack a reverse engineer’s workflow and tools from all sides.

Further, we did all of our obfuscation work inside of a compiler (LLVM) because we wanted our technology to be thoroughly baked into the entire program. LLVM can use knowledge of the program to generate realistic opaque predicates or hide diffused code inside of false paths not taken, forcing a reverse engineer to consult the program’s environment (which might not be available) to resolve which instruction sequences are the correct ones. Obfuscating at the compiler level is more reliable than operating on an existing binary: there is no confusion about code vs. data or missing critical application behavior. Additionally, compiler-level obfuscation is transparent to current and future development tools based on LLVM. For instance, MAST could obfuscate Swift on the day of release — directly from the Xcode IDE.

Symbol Mangling

The first and simplest technique was to hinder quick Objective-C method name retrieval scripts; this is certainly the least interesting of the transforms, but would remove a large amount of human-readable information from an iOS application. Without method or other symbol names present for the proprietary code, it’s more difficult to make sense of the program at a glance.

Opaque Predicate Insertion

The second technique we applied, opaque predicate insertion, is not a new technique. It’s been done before in numerous ways, and capable analysts have developed ways around many of the common implementations. We created a stronger version of predicate insertion by inserting predicates with opaque conditions and alternate branches that look realistic to a script or person skimming the code. Realistic predicates significantly slow down a human analyst, and will also slow down tools that operate on program control flow graphs (CFGs) by ballooning the graph to be much larger than the original. Increased CFG size impacts the size of the program and the execution speed but our testing indicates the impact is smaller or consistent with similar tools.

Code Diffusion

The third technique, code diffusion, is by far the most interesting. We took the ideas of Return-Oriented Programming (ROP) and applied them in a defensive manner.

In a straightforward situation, an attacker exploits a vulnerability in an application and supplies their own code for the target to execute (shellcode). However, since the introduction of non-executable data mitigations like DEP and NX, attackers have had to find ways to execute malicious code without the introduction of anything new. ROP is a technique that makes use of code that is already present in the application. Usually, an attacker would compile a set of short “gadgets” in the existing program text that each perform a simple task, and then link those together, jumping from one to the other, to build up the functionality they require for their exploit — effectively creating a new program by jumping around in the existing program.

We transform application code such that it jumps around in a ROP-like way, scrambling the program’s control flow graph into disparate units. However, unlike ROP, where attackers are limited by the gadgets they can find and their ability to predict their location at runtime, we precisely control the placement of gadgets during compilation. For example, we can store gadgets in the bogus programs inserted during the opaque predicate obfuscation. After applying this technique, reverse engineers will immediately notice that the handy graph is gone from tools like IDA. Further, this transformation will make it impossible to use state-of-the-art static analysis tools, like BAP, and impedes dynamic analysis techniques that rely on concrete execution with a debugger. Code diffusion destroys the semantic value of breakpoints, because a single code snippet may be re-used by many different functions and not used by other instances of the same function.

graph view is useful

Native code before obfuscation with MAST

graph view is useless

Native code after obfuscation with MAST

The figures above demonstrate a very simple function before and after the code diffusion transform, using screenshots from IDA. In the first figure, there is a complete control flow graph; in the second, however, the first basic block no longer jumps directly to either of the following blocks; instead, it must refer at runtime to a data section elsewhere in the application before it knows where to jump in either case. Running this code diffusion transform over an entire application reduces the entire program from a set of connected-graph functions to a much larger set of single-basic-block “functions.”

Code diffusion has a noticeable performance impact on whole-program obfuscation. In our testing, we compared the speed of bzip2 before and after our return-oriented transformation and slowdown was approximately 55% (on x86).

Environmental Keying

MAST does one more thing to make reverse engineering even more difficult — it ties the execution of the code to a specific device, such as a user’s mobile phone. While using device-specific characteristics to bind a binary to a device is not new (it is extensively used in DRM and some malware, such as Gauss), MAST is able to integrate device-checking into each obfuscation layer as it is woven through the application. The intertwining of environmental keying and obfuscation renders the program far more resistant to reverse-engineering than some of the more common approaches to device-binding.

Rather than acquiring any copy of the application, an attacker must also acquire and analyze the execution environment of the target computer as well. The whole environment is typically far more challenging to get ahold of, and has a much larger quantity of code to analyze. Even if the environment is captured and time is taken to reverse engineer application details, the results will not be useful against the same application as running on other hosts because every host runs its own keyed version of the binary.


In summary, MAST is a suite of compile-time transformations that provide easy-to-use, cross-platform, state-of-the-art software obfuscation. It can be used for a number of purposes, such as preventing attackers from reverse engineering security-related software patches; protecting your proprietary technology; protecting data within an application; and protecting your application from vulnerability hunters. While originally scoped for iOS applications, the technologies are applicable to any software that can be compiled with LLVM.

iVerify is now available on Github

Today we’re excited to release an open-source version of iVerify!

iPhone users now have an easy way to ensure their phones are free of malware.

iVerify validates the integrity of supported iOS devices and detects modifications that malware or jailbreaking would make, without the use of signatures. It runs at boot-time and thoroughly inspects the device, identifying any changes and collecting relevant artifacts for offline analysis.

In order to use iVerify, grab the code from GitHub, put your phone in DFU mode and run the iverify utility. Prompts on screen will indicate whether surreptitious modifications have been made. Visit the GitHub repository for more information about iVerify.

iOS 4 Security Evaluation

This year’s BlackHat USA was the 12th year in a row that I’ve attended and the 6th year in a row that I’ve participated in as a presenter, trainer, and/or co-organizer/host of the Pwnie Awards. And I made this year my busiest yet by delivering four days of training, a presentation, the Pwnie Awards, and participating on a panel. Not only does that mean that I slip into a coma after BlackHat, it also means that I win at conference bingo.

Reading my excuses for the delay in posting my slides and whitepaper, however, is not why you are reading this blog post. It is to find the link to download said slides and whitepaper:

Hacking at Mach 2!

At BayThreat last month, I gave an updated (and more much sober) version of my “Hacking at Mach Speed” presentation from SummerC0n.  Now, since the 0day Mach RPC privilege de-escalation vulnerability has been fixed, I can include full details on it.  The presentation is meant to give a walkthrough on how to identify and enumerate Mach RPC interfaces in bootstrap servers on Mac OS X.  Why would you want to do this?  Hint: there are other uses for these types of vulnerabilities besides gaining increased privileges on single-user Mac desktops.  Enjoy!

  • “Hacking at Mach 2!” (PDF)

KARMA Demo on the CBS Early Show

Although I haven’t done any development on KARMA for a little over 5 years at this point, many of the weaknesses that it demonstrates are still very present, especially with the proliferation of open 802.11 Hotspots in public places. A few weeks ago, I was invited to help prepare a demo of KARMA for CBS News and the segment actually aired a few weeks ago. If you’re like me and don’t have one of those old-fashioned tele-ma-vision boxes, you can check out the segment here.

Unfortunately, they weren’t able to use the full demo that I prepared. The full demo used a KARMA promiscuous access point to lure clients onto my rogue wireless network with a rogue network’s gateway routed outbound HTTP traffic through a transparent proxy that injected IFRAMEs in each HTML page. The IFRAMEs loaded my own custom “Aurora” exploit, which injected Metasploit’s Meterpreter into the running web browser. From there, I could use the Meterpreter to sniff keystrokes as they logged into their SSL-protected bank/e-mail/whatever. The point was that even if a victim only uses the open Wi-Fi network to log into the captive portal webpage, that’s enough for a nearby attacker to exploit their web browser and maintain control over their system going forward. Perhaps that was a little too complicated for a news segment that the average American watches over breakfast.

As it has been quite a while since I have talked about KARMA, here are a few updates on the weaknesses that it demonstrated:

  • Windows XP SP2 systems with 802.11b-only wireless cards would “park” the cards when the user is not associated to a wireless network by assigning them a 32-character random desired SSID. Even if the user had no networks in their Preferred Networks List, the laptop would associate to a KARMA Promiscuous Access Point and activate the network stack while the GUI would still show the user as not currently associated to any network. This issue was an artifact of 802.11b-only card firmwares (PrismII and Orinoco were affected) and is not present on most 802.11g cards, which is what everyone has these days anyway.
  • Even with a newer card, Windows XP SP2 will broadcast the contents of its Preferred Networks List in Probe Request frames every 60 seconds until it joins a network. Revealing the contents of the PNL allows an attacker to create a network with that name or use a promiscuous access point to lure the client onto their rogue network. Windows Vista and XP SP3 fixed this behavior.
  • Mac OS X had the same two behaviors, except that Apple’s AirPort driver would enable WEP on the wireless card when it had “parked” it. However, the WEP key was a static 40-bit key (0x0102030405 if I recall). Apple issued a security update in July 2005 and credited me for reporting the issue.
  • On 10/17/2006, Microsoft released a hotfix to fix both of the previous issues on Windows XP SP2 systems that Shane Macaulay and I had discovered and presented at various security conferences over the previous two years.
  • Newer versions of Windows (XP SP3, Vista, 7) are only affected if the user manually selects to join the rogue wireless network or the rogue network beacons an SSID in the user’s Preferred Networks List.

Although the leading desktop operating systems found on most laptops have addressed the issue, most mobile phones now support 802.11 Wi-Fi, which may give KARMA a chance to live again!

Advanced Mac OS X Rootkits

At BlackHat USA 2009, I presented “Advanced Mac OS X Rootkits” covering a number of Mach-based rootkit techniques and some tools that I have developed to demonstrate them.  While the majority of Mac OS X rootkits employ known and traditional Unix-based rootkit techniques, these Mach-based techniques show what else is possible using the powerful Mach abstractions in Mac OS X.  My presentation covered a number of Mach-based rootkit tools and techniques including user-mode Mach-O bundle injection, Mach RPC proxying, in-kernel RPC server injection/modification, and kernel rootkit detection.

User-mode DLL injection is quite common on Windows-based operating systems and is facilitated by the CreateRemoteThread API function.  The Mach thread and task calls support creating threads in other tasks, however, they are much more low-level.  The inject-bundle tool demonstrates the steps necessary to use injected memory and threads to load a Mach-O bundle into another task.  A number of injectable bundles are included to demonstrate the API (test), capture an image using the iSight camera (iSight), log instant messages from within iChat (iChatSpy), and log SSL traffic sent through the Apple Secure Transport API (SSLSpy).

The majority of Mach kernel services (task and thread system calls, for example) are implemented as RPC services.  The Mach message format was designed to be host-independent, which facilitates transferring them across the network.  Machiavelli demonstrates using Mach RPC proxying in order to transparently perform Mach RPC to a remote host. Machiavellian versions of ps and inject-bundle are included in order to demonstrate how this technique may be used for remote host control by rootkits.

Most of the public kernel rootkits for Mac OS X load as kernel extensions and remove their entries from the kernel’s kmod list in order to hide themselves from kextstat and prevent themselves from being unloaded. The uncloak tool examines the kernel memory regions looking for loaded Mach-O objects.  If any of these objects do not correspond to a known kernel extension, they may be dumped to disk using kernel-macho-dump.

Mach IPC messages to the in-kernel Mach RPC servers are dispatched through the mig_buckets table.  This table stores function pointers to the kernel RPC server routines and is analogous to the Unix systent system call table.  A kernel rootkit may directly modify this table in order to inject new kernel RPC servers or interpose on in-kernel RPC server routines.  The KRPC kernel extension shows how a kernel rootkit may directly modify this table in order to dynamically inject a new in-kernel RPC subsystem.

These tools are deliberately released as ‘non-hostile’
proof-of-concept tools that meant to demonstrate techniques and are
not suitable for use in actual rootkits or attack tools.  The IM and
SSL logging bundles log to the local system’s disk in an obvious
fashion and Machiavelli opens up the controlling host to some obvious
attacks.  The non-Machiavelli version of inject-bundle, however, is
fully functional and useful for a variety of system-level tasks.
Using the other tools outside of a closed network or test virtual
machine is not recommended.

These tools are deliberately released as ‘non-hostile’ proof-of-concept tools that meant to demonstrate techniques and are not suitable for use in actual rootkits or attack tools.  The IM and SSL logging bundles log to the local system’s disk in an obvious fashion and Machiavelli opens up the controlling host to some obvious attacks.  The non-Machiavelli version of inject-bundle, however, is fully functional and useful for a variety of system-level tasks.  Using the other tools outside of a closed network or test virtual machine is not recommended.

Here are the goods:

The Mac Hacker’s Handbook is out!

The Mac Hacker’s Handbook by Charlie Miller and myself has just been published and is now shipping from Amazon.  I have even spotted it in several bookstores where you can usually find it in the Mac section.  The book is all about Mac OS X-specific vulnerability discovery, reverse-engineering, exploitation, and post-exploitation.

For me, this book is a culmination of over 8 years of personal Mac OS X security research.  I had bought and restored a NeXTSTATION Turbo Color in college and fell in love with the NeXTSTEP and OpenStep operating systems.  When I got a check for my first pen-test, I bought a brand-new iBook 500 Mhz to run OS X 10.0 on and I have used OS X as my primary operating system ever since.

Of course, I started hacking on it immediately.  I wrote a monitor-mode wireless packet capture driver for AirPort (Viha) back when the only documentation on IOKit was the Darwin source code and a series of emails on the darwin mailing lists from an Apple kernel developer.  And that was just the first part of my WEP cracking project for my Crypto class.  I was so stubborn about using my iBook for it that I wrote my own driver, stumbler, and WEP weak RC4 key cracker for it.

There was also very little documentation on shellcode for PowerPC around then.  Palante and LSD had both released PowerPC shellcode for Linux and AIX respectively.  But there was nothing for OS X.  I wrote this in a hotel room in Washington, D.C. a few days after DEFCON 9.  As far as I know I was the first one to publish PowerPC shellcode that filled in the unused bits in the ‘sc’ instruction instead of dynamically overwriting them because self-modifying code is pretty tricky on PowerPC.  That shellcode is what appears encoded in the hex bytes on the cover of the book.

Alright, enough self-indulgent trips down memory lane.  I just presented “Mac OS Xploitation” at SOURCE Boston last week and I’ll be doing a bigger presentation called “Hacking Macs for Fun and Profit” next week at CanSecWest with Charlie Miller.  Stay tuned here for some more Mac tool releases.

ARM versus x86

At Hack in the Box in Kuala Lumpur this year, I was interviewed by Sumner Lemon of IDG about various Mac and iPhone-related security topics.  One of the topics was the relative security of ARM versus x86 processors and my comments on this seem to have bounced around the internets a bit.  There seems to have been some confusion over what I meant in my statements, so I thought I’d provide some clarification here on the technical and economic rationale behind this statement.

First, the technical rationale: The classic x86 architecture (pre NX-bit) is an exploit developer’s dream.  Almost every other architecture has complications that x86 almost coincidentally does not.  For example, SPARC has register windows, PowerPCs can have separate data and instruction caches, any RISC architecture has alignment requirements, most architectures support non-executable memory, and all of these make writing exploits on these platforms more difficult.  The x86 had none of these speedbumps and only started supporting truly non-executable memory somewhat recently.  Finally, the x86 instruction set is incredibly flexible, allowing all sorts of ingenious techniques for self-modifying code to evade character filters and intrusion detection systems.  Of course, this was all possible on other architectures as well (see ADMutate‘s SPARC support), but x86 makes it way easier and more powerful.  I have a hard time imagining what could be changed in x86 to make a better target for exploit developers.

Since cybercrime and malware has become a significantly sized industry, it makes a lot of sense to analyze the risk presented by it through economics (and game theory).  Attackers have a lot of infrastructure already built that is x86-specific.  Besides exploit development experience, this also includes payload encoders and hand-written assembly exploit payloads.  Rewriting these takes time and effort.  Macs (and iPhones, as postulated in the article) using x86 processors allow attackers to carry over their experience and existing infrastructure, slightly lowering the barrier to entry to begin attacking a new platform.  If a new platform with marketshare X% starts attracting malware authors’ attention, a new platform with a familiar processor may attract malware authors’ attention at (X – Y)% marketshare (where Y is probably less than 10).  In the end, however, this earlier attention most likely matters less to the product vendor than the deep discount or performance improvements they can get by going with a dominant CPU architecture and manufacturer.

In summary, just about any commodity non-x86 CPU-based system is harder to write exploits for than an x86-based system assuming the same operating system is running on both.  But it does not matter because these differences are just speed bumps and a good exploit developer will be able to work around them.  Vendors should focus on the generic security defenses that they can build into their operating systems and application runtime environments as well as focus on eliminating software vulnerabilities before and after their software is shipped rather than caring what processor architecture they use and whatever impact it may have on attacks against their platform.

Finally, I would also like to make a retraction.  In the same interview, I said that I considered the iPhone OS to be “significantly less secure” than the desktop Mac OS X.  While I would still consider the iPhone OS 1.x to be less secure than Leopard, the iPhone OS 2.2 is quite the opposite.  A number of improvements, including a smaller attack surface, application sandboxes, a non-executable heap, and mandatory code signing for every executable launched (not just applications, even low-level binaries) make compromising the special-purpose iPhone more difficult than the general-purpose desktop Mac OS X.  For more details on the security improvements in the latest iPhone OS, see Charlie Miller’s HiTBSecConf presentation.  Of course, this primarily applies to unjailbroken iPhones since a jailbroken iPhone allows execution of unsigned binaries and it seems that most jailbroken phones still have an SSH server running with the default root account password anyway.  Qualitative comparisons of security are very difficult to whittle down into a one sentence summary, but that’s why organizations (hopefully) have security analysts around and don’t make all of their decisions based on what they read on the Internet. Vulnerability Analysis

Apple recently released Mac OS X 10.5.4 with accompanying security updates for 25 vulnerabilities.  Notably absent, however, is a fix for the recently brouhaha’d local privilege escalation vulnerability.  The exploit is extremely simple and unfortunately, it seems that the fix is not; otherwise Apple would have fixed it in this batch.  For more information on the exploit including temporary fixes and workarounds to protect yourself until Apple fixes this vulnerability, see the full write-up at

In the interest of fully understanding Mac OS X security issues, let’s dive in and see how this vulnerability works.  As a reminder, the vulnerability is that, a set-user-id root executable, responds to the “do shell script” Apple Event, effectively running arbitrary commands as root.

Applications must announce that they can receive Apple Events before they may be scripted.  In Cocoa applications, this is done by setting the NSAppleScriptEnabled property to “YES” in the application bundle’s Info.plist file.  In Carbon applications, an application is made scriptable by simply calling the AEInstallEventHandler() function.  AEInstallEventHandler() lets the application define which Apple Events it can handle and supply the handler functions for them. did not do anything special in order to respond to the “do shell script” Apple Event, this event is defined in the StandardAdditions Scripting Addition in /System/Library/ScriptingAdditions.  Scripting Additions are dynamic libraries (dylibs) that will be loaded automatically by the Apple Event handler if the application receives an Apple Event that is defined in them.  There are several Scripting Additions in /System/Library/ScriptingAdditions, but they may also potentially be found in /Library/Scripting/Additions or ~/Library/ScriptingAdditions.

Interestingly, calls AESetInteractionAllowed() with kAEInteractWithSelf after installing its own Apple Event handlers which is supposed to restrict the processing of Apple Events to only those sent by the process itself.  It obviously does not seem to have its intended effect in this case.

This is a pretty isolated vulnerability not a massive security hole in AppleScript.  Set-user-id executables should not be scriptable and appears to be the only application that violates this.

UPDATE @ 20080704: As mentioned in the MacShadows security forums from the link in the comments below, SecurityAgent is also susceptible to this, but only when SecurityAgent is running with increased privileges (after a sudo, unlock of System Keychain, etc). But this is not because SecurityAgent is setuid, it is because it still receives Apple Events when it runs with increased privileges. It doesn’t, however, appear to call any Apple Events functions. So I am not sure why it is processing Apple Events (handled in a base framework?). If anyone knows why, let me know.

UPDATE @ 20080705: I have poked around at this a bit more this weekend, and it turns out that an application does not need to call any Apple Events APIs in order to receive and process Apple Events.  While Cocoa applications must set the NSAppleScriptEnabled property, any Carbon application automatically handles Apple Events.  At the lowest level, Apple Events are sent over Mach ports looked up from the bootstrap server, so you need port send rights in order to send it Apple Events.  This means that a client will not be able to send events to an application running as a different user unless it is setuid/setgid (ARDAgent) or is run with increased privileges, but still checks its ports in with the bootstrap server (SecurityAgent, which is launched by securityd with gid=0 on Tiger in certain situations).

ARDAgent Exploit, MacOS X Malware, and Snow Leopard, Oh My!

As also reported by Intego and Matasano, a new local privilege escalation vulnerability has been found that gives local root access on MacOS X Tiger and Leopard.  While Intego calls this a critical vulnerability, I’m mostly with Ptacek on this one where I am saying this vulnerability is not nearly that serious.  For one, it only works when it is run as the user who is logged into the console.  This means that no MacOS X servers are affected by this, but it can allow a web exploit or trojan horse to gain root access without the user’s knowledge or permission.  Also while root access is pretty serious, it is not necessary in order for the malware to do bad things to your system (i.e. install itself to run automatically, backdoor Safari, etc).  So I will dub this a serious, but not critical, vulnerability.

Perhaps the most interesting fact about this vulnerability is where it came from: a  thread (from Google cache because the forums seem to be down now) on the forums at Mac Shadows, a mac underground web site.  The aforementioned thread was discussing how to build AppleScript-based trojans until “callmenames” discovered the vulnerability and the discussion moved towards the vulnerability and ensuing news and attention.  And at the time of writing, the forums on the site have been taken offline.

The big question on everyone’s mind is when malware will begin to seriously affect MacOS X and what will happen when it does.  As for when, I am betting that it completely depends on market share, as per Adam O’Donnell’s game theoretic analysis.  As for how bad, that will all depend on Snow Leopard: when it will ship, how it will improve MacOS X security, and how many users will install it.

Snow Leopard will hopefully raise the bar for MacOS X as much as Vista did for Windows.  Of course it won’t stop all security attacks, but it should make exploiting them beyond the reach of most attackers.  I’d personally like to see the following improvements:

  • Real address space layout randomization.  Library randomization with dyld loaded at a fixed location just doesn’t cut it.
  • Full use of hardware-enforced Non-eXecutable memory (NX).  Currently, only the stack segments are enforced to be non-executable.  Welcome to the new millennium where buffer overflows aren’t only on the stack.
  • Default 64-bit native execution for any security-sensitive processes.  I don’t particularly care that it may waste 5% more memory and a little bit of speed, I want Safari, and just about everything else that has security exposure to run as a 64-bit process.  Simply because function arguments are passed in registers rather than on the stack, this makes working around ASLR and NX damn near impossible for many exploits.
  • Sandbox policies for Safari,, and third-party applications.  Code execution vulnerabilities aren’t the only kind of vulnerabilities and good sandbox policies for security-exposed applications can help mitigate the exploitation of code execution and other vulnerabilities in these applications.  I love the scheme-based policies, by the way.
  • Mandatory code signing for any kernel extensions.  I don’t want to have to worry about kernel rootkits, hyperjacking, or malware infecting existing kernel drivers on disk.  Most kernel extensions are from Apple anyway and for the few common 3rd party ones, they should be required to get a code signing certificate. 

I’m hoping that Snow Leopard ships before we see too much Mac malware, fixes all of the above, and that it is a free upgrade.  Yes, I know that’s unlikely, but users will not pay money for security features.  When users don’t upgrade and are subjected to malware, Apple may still get a bad rap for it.


Get every new post delivered to your Inbox.

Join 3,629 other followers