Resting on One’s Laurels
In a recent article iPhone shell code hits the web HD Moore, creator of the Metasploit Framework describes how combining members of a set of implementation bugs in applications on Apple’s iPhone with a design flaw results in a ripe opportunity for landing shell code or otherwise controlling the phone’s various hardware goodies (camera, mic, speaker, etc.) remotely.
As you read the above article, note the classic vulnerability-types mentioned. The iPhone suffers from a design flaw: all apps running as root. Moore also mentions some of the simplest kinds of buffer problems (such as the stack-based buffer overflow).
These bugs, this flaw represent a low-level of organizational maturity in security. It almost seems a throw-back to any 90’s era code assessment I’d done. We’ve understood the stack-based buffer overflow well for years-upon-years and even rudimentary static analysis tools catch it. Threat modeling or simple architectural analysis should have dissuaded architects from moving forward design intact, bearing so fundamentally “risk amplifying” a flaw as “run as root”.
Make no mistake: Apple represents a company leveraging security by obscurity. I cringed when Apple used its then largely untarnished record as a marketing ploy, (from what I understand) without listening to what’s been said about the actual resistance of his products to attack.
While aspects of their desktop OS were truly “designed with security in mind” and represent solidly secure OS technology, it’s clear to me that Apple does not address software security programmatically to what I consider an acceptable level.
When Apple created an asset of reasonable enough value and appeal, threats easily broke a shoddy system by retraining their attention on the protective mechanisms shielding that asset.
While a lot of our customers have adopted software security early, and have committed to addressing it in all phases of their software’s lifecycle, in all appropriate organizations touching software, others have not. If, reading this, you look at the well-covered transition from Microsoft to Apple as the vulnerability target and think by analog, “this stuff is happening to my competitor, but can’t happen to me”, or perhaps feel invulnerable because, “No one would figure these vulns. out.” or, “We’re not on people’s radar.” BEWARE. One ostrich is having to pull its head out of the sand and peck at crow… and this is sad because, with the exception of my Crackberry, I largely believe in and purchase from Apple.
A final thought: Regardless of the actual security in OS X, what chance does Apple have of touting Leopard’s security over Vista in the market place after these events?
September 27th, 2007 at 5:10 pm
“A final thought: Regardless of the actual security in OS X, what chance does Apple have of touting Leopard’s security over Vista in the market place after these events?”
None whatsoever, considering many of the best security people in the world today have audited Vista’s code. Apple needs to look seriously at doing the same thing. They shouldn’t be singled out for their vulnerabilities because nearly every vendor is vulnerable until they pro-actively do something about it. And being proactive means hiring the right people to audit your products. When vendors refuse to acknowledge the security problem it just makes it worse.