Relative Security of the ARM vs. x86 architectures
At the Hack in the Box conference in Kuala Lumpur, Malaysia at the end of last month, Dino A. Dai Zovi (formerly of Matassano & @stake) made some comments about the relative security of the ARM vs. x86 architectures. He was quoted as saying “That [the use of an x86 processor] will make the iPhone x86 and that will make a lot of attacks easier…” in an InfoWorld article which as was blogged about by Joel Hruska on the ArsTechnica website in an article called ‘Researcher: ARM a safer bet than x86 chips’.
Dai Zovi is an increasingly well-known cyber security research. He won the April 2007 MacBook hacking contest, presented at Black Hat on Hardware Virtualization Rootkits and at Hack in the Box on Mac OS XPloitation. A podcast interview with Dai Zovi is available SearchSecurity.com.
If Dai Zovi is correct and the ARM chips are indeed a safer bet from a security point of view than the x86 chips that is of course very important news from a control systems security point of view. ARM chips are used in control systems technology, specifically some PLC’s. Although HMI level technology is usually x86, mission and safety critical systems are generally PLC controlled. If one chip architecture provides a better security foundation than another, that would be an argument for preferring that architecture, especially for mission & safety critical systems.
Unfortunately, the InfoWorld quote doesn’t really give much information about what Dai Zovi actually said. Hruska asserts that Dai Zovi’s argument rests on a security by obscurity argument; that is, that the only reason x86 are more vulnerable is that they (and therefore exploits against them) are more common. From Kevin Lackey’s previous DigitalBond threads I think we already had a pretty good discussion of the danger of taking ’security by obscurity’ arguments to far. I basically hold with the adage ’security by obscurity is absurdity’. But even if less popular systems, (a.k.a. more ‘diverse’ systems) are really not inherently more secure, they might be less attractive targets. Exploit tools are less generally available for obscure platforms. That makes attacks against those kinds of systems more expensive. But that is not the discussion I am hoping to start today.
Another ‘theoretical’ argument is that the ARM chips, like the PowerPC chips are RISC rather than CISC based. Some security researches assert that in general, the more complicated something is the more difficult it is to secure. By that argument one might assert that because RISC based chips are simpler, at least at the time of the initial design, they might provide a better foundation for building secure systems.
In Hruska’s review of the Dai Zovi claims, Hruska suggests that a serious comparison of the security properties of the ARM and the x86 chips should “account for the protective mechanisms built into both a device’s OS and its actual hardware” which seems pretty sensible.
This brings me to the discussion I am hoping to start. Do some chipset architectures provide a better security foundation for PLCs and if so, which one’s and why? Or, are there so many issues after the initial chipset architecture decision that the security implications of one chip architecture over another is really just in the noise?
Author: Martin Solum
Posted: November 9th, 2008 under Uncategorized.
Comments: 10
Comments
Comment from Dino Dai Zovi
Time: November 9, 2008, 8:26 pm
Of course, this is a much more complex issue that can’t be summed up as “architecture X is more secure than architecture Y” because you also have to complete the sentence with what attacks it is more secure against.
My comments were basically that writing exploits for x86 is much easier than just about any other architecture. Everything from the unified cache to the instruction set encoding to the lack of alignment requirements makes a lot of things much easier for the attacker. Given that, moving the iPhone from an architecture that is pretty unknown to most attackers to one that is very well known would make potential attackers’ jobs easier.
This of course can be mitigated by adding more defenses within the operating system. At this point, features like full address space layout randomization and non-executable memory segments should be considered as required features in a modern operating system as separate address spaces.
Comment from Matt Franz
Time: November 9, 2008, 8:56 pm
Maybe things like TrustZone?
Back in early 2004 (or 2005, long time ago) Venkat & I scoped out (but never completed or published on) an Embedded/RTOS Security project at Cisco I definitely recall reading about some hardware security features within some ARM models.
Of course, the choice of RTOS is also going to be a factor.
Comment from Joel Hruska
Time: November 9, 2008, 9:13 pm
Hey Martin,
I’d appreciate it if you could link the Kevin Lackey discussion on security through obscurity that you mention above–I tried to search Digitalbond for it, but got page load errors when attempting to view the archives or search the site.
I think Intel’s Trusted Execution Technology may be the best example of hardware-enforced code security, but I can’t swear to it by any means. I know that a full TXT implementation (which requires specific motherboards and processors) can completely sandbox a process away from the rest of the system, though this becomes moot if TXT itself is easily hackable.
My point is ultimately less about CPU architectures and more about economics. If Dino Dai Zovi is correct–and I’ve got no reason to think he isn’t–x86 is inherently one of the easiest architectures to exploit. If x86-based smartphones became widespread, only to fall victim to unique x86 hacking, Intel would have no choice but to find a way to deliver a protected execution mode while remaining within a cell phone’s power envelope.
If, on the other hand, ARM remains the dominant standard, and continues to spread through all the cell phones of the world, I believe enterprising malware authors *will* eventually invest in the tools and expertise that are required to exploiting ARM.
Malware vendors increasingly operate according to corporate business models. In the end, I think this entire discussion is very theoretical–Intel doesn’t have the products it needs to push into this space, and it may not have them for another few years.
I’m 100% willing to accept that ARM is inherently more secure than x86, but I’m not convinced that buys us anything but a little more time. I believe that the vast majority of people who come online in the next 10 years will initially do so on a smartphone or MID. I further believe that malware vendors will follow that trend and find ways to inject their poison into this new ecosystem. If the cost of those long-term profits is some up-front costs, well, that’s business.
Choosing ARM over x86, as I’ve said, might buy us some time, but I’m not sure it gets us anywhere different in the long run.
Comment from Jake Brodsky
Time: November 10, 2008, 8:15 am
So the argument, if I understand it correctly, is this: (bear with my bicycle lock analogy) If we have bolt cutters lying all over the place, one of those “Kryptonite” bicycle locks ought to do pretty well. However, if cans of freon freeze spray and hammers are easier to get to, then the Kryptonite lock is more vulnerable.
Neither lock is proof against an attack. It’s merely a matter of what tools are most commonplace. And if the experience with OS X from Apple is any guide, there may be some merit to this argument.
Comment from Martin Solum
Time: November 10, 2008, 10:58 am
Dino and everyone, thanks all for the great comments so far…
Matt, trustzone looks really interesting, especially for the handset market. Of course the big question is, does it introduce insurmountable or not cost justifiable comlexity/performance issues in a hard real-time control system environment?
Joel, here are some links to Kevin Lackey posts I was referring to. They are not specifically on ’security by obscurity’ but it is mentioned.
Putting the genie back into the bottle
http://www.digitalbond.com/index.php/2008/08/28/putting-the-genie-back-into-the-bottle/
Attack vectors for physical damage on control systems
http://www.digitalbond.com/index.php/2008/04/22/attack-vectors-for-physical-damage-on-control-systems/
Jake, I think the bicycle lock analogy captures the gist of the ‘buying time’ argument correctly. I often use the older ‘the Club’ analogy. ‘The Club’ was that steering wheel lock for cars. For a while it discouraged the amateurs but the pros just used there bolt cutters on the steering wheel instead of ‘the Club’.
But, analogies only go so far. Developing an exploit toolset against a different chip architecture takes more mental horsepower (and $$$) than our cute bicycle lock and steering wheel lock examples. On the other hand, it is not that big a trick for a funded determined adversary to identify engineers with the requisite skill sets.
Comment from Martin Solum
Time: November 11, 2008, 8:02 pm
I keep thinking about the key sentence from Dino’s comment.
“Everything from the unified cache to the instruction set encoding to the lack of alignment requirements makes a lot of things much easier for the attacker.”
That is just not near a security by obscurity argument. That is an architecture defects argument.
Comment from Dean Murray
Time: November 12, 2008, 8:45 pm
Not really relevant in the ARM vs x86 argument but I suppose you could argue that proper Harvard architecture (preventing execution of data) would be inherently more secure since it would not be vulnerable to stack overflows and the like?
Comment from Martin Solum
Time: November 18, 2008, 10:54 am
So Dean, that’s really a pretty cool comment. It definitely follows.
I didn’t actually understand your comment when I first read it but thanks to 15 minutes with Wikipedia, it makes perfect sense. I thought I’d elaborate in case others weren’t familiar with the “proper Harvard architecture”.
I didn’t even know that there was a Harvard architecture (see link below) that competed with the dominant von Neumann computer architecture before reading your comment. (Although interestingly, I mentioned it to a hacker friend of mine who new immediately what you were talking about.)
The thing is, the main take-away from the first couple of chapters of the ShellCoder’s Handbook (see link below) is that when instructions and data get confused bad things can happen. Since in the Harvard architecture there are “physically separate storage and signal pathways for instructions and data.” (see link below) at least theoretically, bad things are less likely to happen.
I was really thinking this was cool when I found out the PIC microcontroller chips (see link below), a popular inexpensive choice for embedded systems, are based on the Harvard architecture. Unfortunately, it turns out that the PIC chips have some odd little cyber security issues. See: Flylogic’s Unmarked Die Revisions (see link below)
Still, it’s interesting from a control system cyber-security point of view. I’m thinking the main driver that makes von Neumann so much more common in the IT technology world is a convenience issue because in the IT world code frequently get’s updated. MAYBE, since in the control technology world systems last many, many years, the potential cyber security benefit of Harvard architecture chips might out-weigh the ease of update convenience of the prevalent von Neumann architecture based chips.
-Martin
links-
ShellCoder http://www.powells.com/biblio/2-9780470080238-0
Harvard Architecturehttp://en.wikipedia.org/wiki/Harvard_architecture
PIC controller http://en.wikipedia.org/wiki/PIC_microcontroller
Flylogic’s Unmarked Die Revisions http://www.flylogic.net/blog/?p=9
Comment from Dean Murray
Time: November 18, 2008, 8:40 pm
Thanks Martin,
Actually when I said “Not really relevant in the ARM vs x86 argument” I don’t know if that is strictly true. Some ARM cores might actually be Harvard?
Regarding ease of update it is true that von-Neumann is more flexible, but with many “Harvard” devices being so called “Modified Harvard”, updates to program code can still be done without special programmers. They have special instructions to write the program memory, with a boot-loader program the main program code can be updated (ie load new firmware). So for embedded, task specific devices, there really is no disadvantage that I can see.
As for the PIC vulnerability it is very interesting, though it does seem that a silicon level attack is pretty advanced and not in the same class as remotely executable stack overflows etc. Maybe its more relevant for smartcard / encryption devices where PIC’s are also used. After all we are not talking about invulnerability just removing one major attack vector.
Another microcontroller that you may be interested in researching is the AVR
Pingback from ARM versus x86 « …And You Will Know me by the Trail of Bits
Time: December 9, 2008, 10:35 pm
[...] 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 [...]
Write a comment