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.