Book wormsFather and son team write the book on embedded systems security. Plus a flaw a day for Android.
It's a been a few months since my last blog; I apologize for the lack of communication, silence made necessary by a just cause: putting the final touches on a book whose subject matter is hopefully near and dear to your heart: Embedded Systems Security: Practical Methods for Safe and Secure Software and Systems Development (Newnes/Elsevier, 2012). The book is co-authored by my father, an EE who has developed NSA-certified crypto chips and network security devices over the past five decades.
Why write it? Rest assured, such a techie reference book is not a moneymaking proposition for its authors. We devoted our personal time, evenings and weekends over the past year because we felt that in our roles in providing security guidance to embedded systems developers, we owed it to ourselves and the industry to plug a gaping hole--the lack of a comprehensive guide for security topics germane to the embedded engineering community. You can get a better synopsis online, but the book ranges broadly, from secure embedded software development techniques and run-time systems software considerations to crypto and network security/data protection protocols, with a healthy dose of practical case studies--so there's something there for engineers and managers at any level of experience.
Now I'd like to turn your attention to the latest worm gaining headlines--OSX Flashback, a Java vulnerability that has been used to infect hundreds of thousands of Mac OS X computers worldwide. For years, many have asserted that Linux is more secure than Windows. Now Android (built on Linux) is the security laughingstock of the mobile world. Some have asserted that OS X is more secure than Windows or Linux. Neither assertion is true. Such comparisons are comical; the number of reported vulnerabilities in these products, which essentially have the same level of assurance (very little), is simply a function of their relative obscurity. All else being equal, open-source products tend to have higher reported (vs. actual) vulnerabilities because the attackers find them more easily, given the source code. And more significantly, the larger the user base, the more likely attackers will target the product for fun or profit.
With Apple computers enjoying market share gains, Flashback is but one of many high profile attacks we will see on this platform. Check out this fun article from Forbes explaining how it costs four times more to purchase an iOS zero-day than an Android zero-day. But rest assured, zero-days can be bought for any popular mobile or PC operating system.
They are all security Swiss cheese because they suffer from the same development problems: monumental complexity and churn coupled with monolith (vs. modular) design, lack of formal development processes, and poor privilege/access control models.
A recent example of this poor privilege model is CVE-2012-1182, a flaw in the Samba network file system reported a couple weeks ago that has been used to commandeer Linux over a network. Because unauthenticated, unsophisticated remote attackers can exploit it to execute arbitrary code, this vulnerability has been assigned the worst possible severity score: 10.0. Some of you using Linux will read this and think, well I needn't worry--I don't use Samba in my embedded system. That's not the point. The point is that a flaw in a USER MODE process opens a hole that a script kiddie can drive a truck through. The Linux system architecture encourages, even forces, applications to hold excessive privilege in order to get their job done. Why should Samba have the right to access any file, process, I/O device, and physical memory location? It shouldn't.
Then of course there are the code flaws in the operating systems themselves. I estimate that about 1 flaw is added to the Android code base every single day. If you add in custom Android software (e.g. GUI frameworks) developed by mobile OEMs, that rate is really conservative. Don't get me wrong; I'm a big fan of Android and iOS. I have several Android devices and written apps on the iOS App Store. I'm typing this on Mac OS X. But I won't trust any of them to protect high-value information.
The good news is that these security concerns are pragmatically solvable. While you can't retrofit highly assured security to a complex software product not designed for it, you can retrofit at the system level by inserting a software root of trust (ideally tied to a hardware root of trust) beneath the hopelessly insecure thing, and then carefully extracting the most critical security pieces out so they can be hosted by the root of trust and protected from the wild wild west. Trying to retrofit security to a general purpose OS (see: SE Linux, SE Android, Tomoyo, grsecurity, jails and OS containers, Type-2 hypervisors) is like putting a padlock on a screen door. The padlock may deter the novice; it won't defeat the well-funded, sophisticated attacker.
Then developers need to build their own high-assurance, application-level security functions on top of this core root of trust. To do that, they need to be trained on secure development processes. Use a stable base; then compose system stability from the stable base. And make sure the stable base still allows developers to add the bells and whistles that modern electronics need.
Simple concepts, but applying them requires creativity, determination, and vision. You can read a lot more about it in Chapters 2 and 3.
Dave Kleidermacher is CTO of Green Hills Software and a coauthor of Embedded Systems Security. He writes about security issues, sharing his insights on techniques to improve the security of software for highly critical embedded systems.