DaveK’s Embedded Security Blog
Comment
ahshabazz
In defense of Android (I volunteer my time to help triage bugs for the google ...
Steve_B
I honestly wasn't dinging the author of this story -- his points are ...
Angry Bird droppings
Dave Kleidermacher
12/14/2010 10:09 AM EST
Is this a story about Android or a scene from a Hitchcock movie?
Last month, the results of a static source code analysis of Android were published, exposing more than 350 vulnerabilities. A static analyzer can find roughly 10% of the bugs in general-purpose software (an automated analyzer simply cannot grok semantic flaws). Thus, it is safe to assume there are thousands more latent bugs throughout Android, on top of the thousands in Android's underlying Linux kernel.
The analysis was followed days later by disclosure of the Angry Birds hack in which an Android app, which happens to be a spoof on the popular Angry Birds game, exploited a serious vulnerability in Android, allowing the downloaded app to install other arbitrary (and malicious) apps from the Android app store without the user's permission.
These are not the first serious security problems for Android, and no different from iOS or WP7, we know there will be a steady stream of such reports in the future. Android's woes once again highlight the inadequacy of general-purpose operating systems for managing high-value resources exposed to sophisticated attackers. For example, corporations or governments that permit smartphone access into their sensitive intranets must assume that determined hackers will exploit OS vulnerabilities to get in.
The good news is that despite the infeasibility of securing Android itself, Android-based smartphones can be made secure for critical functions like corporate network access, financial transactions, and electronic medical records (EMR) management. The answer lies in virtualizing Android with a secure hypervisor that can strongly isolate critical components beyond the reach of Android's vulnerabilities, malware, and external attacks. Critical components may include cryptographic algorithms and keys, DRM subsystems, network security protocols, anti-malware virtual appliances, and even separate virtualized instances of Android. Recent advances in mobile SoC technology have made this approach practical with respect to performance, maintainability, and cost. The security kernel/hypervisor is an immensely powerful yet mostly hidden (to the end user) layer of software goodness. We don't make the smartphones you buy; we make the smartphones you buy better.
Surprisingly, VMware made it known this month that it has deep sixed its Type-1 hypervisor for mobile devices, going instead with the Type-2 approach it has been marketing for laptops and desktops. VMware is making silly security claims about this, but to no surprise: back on June 2, 2008, VMware announced that its virtualization products could now be used for "sensitive, government environments that demand the strictest security". On June 5, just three days later, severe vulnerabilities in these "secure" hypervisors were posted to the National Vulnerability Database. Among other pitfalls, the vulnerabilities "allow guest operating system users to execute arbitrary code."
A Type-2 approach is fundamentally flawed when it comes to security because VM isolation is dependent upon a general purpose OS (e.g. Android). Is there a market for Type-2 hypervisors in smartphones? Yes--software reuse is an obvious win. Should you trust it to protect high value resources? Not unless you want more Angry Bird Poo.
Dave Kleidermacher is CTO of Green Hills Software. He writes about security issues, sharing his insights on techniques to improve the security of software for highly critical embedded systems.
Last month, the results of a static source code analysis of Android were published, exposing more than 350 vulnerabilities. A static analyzer can find roughly 10% of the bugs in general-purpose software (an automated analyzer simply cannot grok semantic flaws). Thus, it is safe to assume there are thousands more latent bugs throughout Android, on top of the thousands in Android's underlying Linux kernel.
The analysis was followed days later by disclosure of the Angry Birds hack in which an Android app, which happens to be a spoof on the popular Angry Birds game, exploited a serious vulnerability in Android, allowing the downloaded app to install other arbitrary (and malicious) apps from the Android app store without the user's permission.
These are not the first serious security problems for Android, and no different from iOS or WP7, we know there will be a steady stream of such reports in the future. Android's woes once again highlight the inadequacy of general-purpose operating systems for managing high-value resources exposed to sophisticated attackers. For example, corporations or governments that permit smartphone access into their sensitive intranets must assume that determined hackers will exploit OS vulnerabilities to get in.
The good news is that despite the infeasibility of securing Android itself, Android-based smartphones can be made secure for critical functions like corporate network access, financial transactions, and electronic medical records (EMR) management. The answer lies in virtualizing Android with a secure hypervisor that can strongly isolate critical components beyond the reach of Android's vulnerabilities, malware, and external attacks. Critical components may include cryptographic algorithms and keys, DRM subsystems, network security protocols, anti-malware virtual appliances, and even separate virtualized instances of Android. Recent advances in mobile SoC technology have made this approach practical with respect to performance, maintainability, and cost. The security kernel/hypervisor is an immensely powerful yet mostly hidden (to the end user) layer of software goodness. We don't make the smartphones you buy; we make the smartphones you buy better.
Surprisingly, VMware made it known this month that it has deep sixed its Type-1 hypervisor for mobile devices, going instead with the Type-2 approach it has been marketing for laptops and desktops. VMware is making silly security claims about this, but to no surprise: back on June 2, 2008, VMware announced that its virtualization products could now be used for "sensitive, government environments that demand the strictest security". On June 5, just three days later, severe vulnerabilities in these "secure" hypervisors were posted to the National Vulnerability Database. Among other pitfalls, the vulnerabilities "allow guest operating system users to execute arbitrary code."
A Type-2 approach is fundamentally flawed when it comes to security because VM isolation is dependent upon a general purpose OS (e.g. Android). Is there a market for Type-2 hypervisors in smartphones? Yes--software reuse is an obvious win. Should you trust it to protect high value resources? Not unless you want more Angry Bird Poo.
Dave Kleidermacher is CTO of Green Hills Software. He writes about security issues, sharing his insights on techniques to improve the security of software for highly critical embedded systems.
|
|
|
|
|
Navigate to related information
przemek
12/20/2010 5:23 PM EST
Dave makes an argument for separation into a highly secure, minimal functionality host VM and general purpose, compatible and functional OS guest. This approach trades off better 'defense in depth' due to diversity, against increased complexity and cost.
Is it a good trade-off? It may be for the highly demanding environments, but there are two assumptions that need to be understood. First, it assumes that the guest-host boundary is inviolate. There's a significant number of vulnerabilities targeting the virtualization area and they aren't as well understood as the traditional malware, so one has to be careful. Remember that host subversion practically guarantees that any guest security mechanisms will be completely ineffective.
Secondly, even if both host and guest are secure and working as designed, high functionality of hosts can lead to unforeseen vulnerabilities with nothing more than regular user privileges---root is not required if you can 'social engineer' the user to run a program that sends spam in the background using their email directory, or steals their passwords.
The executive summary here is that isolated technologies won't guarantee security or correct operation---proper design of the entire system is more important.
Sign in to Reply
Steve_B
5/16/2011 2:19 PM EDT
The big problem with security is that it's a weak-link phenomenon. It doesn't matter how many padlocks you put on the doors if the windows are wide open (no pun intended). The problem with the large, complex software bases that are running phones and PC's these days is that nobody even knows where all the windows are, much less how to lock them.
One of the biggest problems with modern systems is humans. Without reducing the capability you offer them, and the opportunities to make mistakes that come with that power, it's hard to make anything truly secure. If you make a browser incapable of accessing your income tax data, for example, you can't use it to upload your tax return. The more capability you take away in the name of security, the more a security-clueless programmer has to put back as a "feature".
Thank heavens the embedded world has many places where humans aren't so tightly in the loop, so the number of defect opportunities is reduced. Unfortunately, they are STILL in there, just being allowed fewer opportunities to mess up -- for example, in making a mistake setting up a "trusted" network by not realizing that the firewalls in very few routers filter IPv6 traffic. Or forgetting to change the default passwords on routers INSIDE a firewall, allowing one compromised machine to spread contagion through an entire network (a hallmark of advanced persistent threats).
If ANYBODY tells you this is easy, and that their product will make your systems secure, it's easy to tell whether they're lying or mistaken: their lips are moving.
Sign in to Reply
cdhmanning
5/16/2011 2:22 PM EDT
Beware the salesman! Anyone surprised that the CTO of GreenHills makes such a big deal of problems - potential and real - in Android and other competing products?
I personally reviewed some of those Coverity issues and all of them were benign, though I did clean the code up so as to no longer upset Coverity. Don't get me wrong, I think Coverity is great.
The whole point of running those Coverity checks should not be lost. That has **found** problems, and potential problems so that they can be **fixed**.
The rule-of-thumb that Coverity will only find 10% of errors is perhaps true in lightly tested code. However, like all rules-of-thumb, this does not necessarily carry to all code bases. Most of the Linux kernel undergoes extensive testing which would reduce that ratio significantly.
It is also alarmist to suggest that phone application security problems, or problems with apps on the App Store, will undermine an Android-based product that does not use these features. If you had an Android based embeded system it would not be downloading and running random apps from an app store.
There are no one-size-fits-all solutions. Android will suit some applications but not others, but FUD like this does not help anyone.
EETimes: you really need to try mark scare stories from competitors better!
Sign in to Reply
Steve_B
5/16/2011 2:50 PM EDT
I honestly wasn't dinging the author of this story -- his points are more-or-less correct about hypervisors (I'm very familiar with three different type-1's, including the abandoned VMWare one), and I don't think he made any claims that their type 1 hypervisor fixed every problem.
My point was that the hypervisor is not the only thing you need to worry about. This article was focussing on the quality of one padlock, and security-inexperienced designers probably have dozens of problems that are at least as important to fix, and some of them far more important, than this one, and that they shouldn't be lulled into a false sense of security after putting one problem to rest. And in fact, since this IS one they know about, they should pick a good enough solution for their purposes.
I once worked for a company that issued a challenge to break our "secure" system. We lost, not because of a software issue, but because someone tricked an administrator. Something to remember: hackers don't go where you want them to, like to try to hack a secure hypervisor, they go where THEY want to... like a known defect in a years-old unpatched version of Linux or Windows.
Sign in to Reply
ahshabazz
8/9/2011 4:42 AM EDT
In defense of Android (I volunteer my time to help triage bugs for the google team: "Getting Involved - The Chromium Projects" - http://www.chromium.org/getting-involved), the c++ coding convention as implemented by google ensures for secure and high performance code. However issues arise when developers deviate from this style guide, (for example, inlining constructors in header files). Such deeds may seem innocent, but if this code were to fail, this leaves the class in an ill-defined state which may undermine the security properties in the style-guide. Developers that employ such practices are being discovered and subsequently removed from the team.
Sign in to Reply