anti-malware solutions to secure popular mobile platforms almost as an afterthought. But, what is it doing to explicitly address security early on, such as with the SDKs developers use to write mobile applications? Leviathan Security Group's David Kane-Parry, who regularly presents on mobile security was kind enough to update me. I gave the top four mobile vendors opportunity to chime in as well, and some did.
Security surrounding acquiring your kit
The first security concern with mobile SDKs appears before developers even download the kits. A proof of concept has existed for some time, introduced by Unix co-creator Ken Thompson, which demonstrates that hackers may attack mobile SDKs by distributing modified copies of the kits with Trojan/backdoor code already inserted in them. Though neither I nor Kane-Parry are aware of any reports of such modified distributions, developers should get their kits directly from the vendor to avoid such risks.
To help ensure the kits come from the vendor, developers should look for SSL connections at download time and signed certificates that come with the software. RIM distributes its Blackberry SDK as part of the Blackberry Plug-In for the popular, third party Eclipse IDE. To ensure secure transmission direct from RIM, the company distributes the plug-in over an HTTPS connection. The Eclipse IDE however, which is the development environment that RIM officially supports is distributed via HTTP. Both the iPhone and Android SDKs are available over an HTTPS connection as well; the Windows Phone 7 SDK is not.
Once the developer has downloaded the kit, they should look for signed certificates from authorities like VeriSign (now owned by Symantec) or eTrust (CA Technologies) to increase confidence that the SDK came from the vendor. All four of the major platform SDKs use code signing to some degree, some more than others.
The Windows Phone 7 SDK uses a cryptographic hash and a certificate-based digital signature of the hash appended to the SDK installer. The OS checks the hash, signature, and the certificate before installing the SDK.
SDKs Aid Secure Coding
The Android SDK writes apps that do not load native libraries at the same address each time. Developers call this technique Address Space Layout Randomization (ASLR). ASLR increases the difficulty for a hacker counting on a specific library function loading at a known address so he can call it as part of his exploit. ASLR is primarily useful for iPhone apps because they do not run in a virtual machine. ASLR is a substantial roadblock to hackers targeting other platforms as well.
"ASLR is a post-exploitation mitigation technique, in that it increases the difficulty for an attacker who has successfully overflowed a buffer from doing anything useful, either by making the address of useful libraries unpredictable or by making the address of the overflowed buffer unpredictable. If the attacker cannot overcome ASLR, overflowing the buffer will merely crash the application," says Kane-Parry.
Google has improved Android's implementation of ASLR since its appearance to increase the amount of randomization used to select an address at which to load the library. The iPhone has also since implemented ASLR, though it used to load libraries at readily discoverable addresses.
The Android SDK also takes advantage of several security technologies including the ARM No-eXecute capability, ProPolice, which helps to prevent stack overflows, and safe IOP, for safe integer operations, according to Google. These technologies prevent code executions that are a consequence of memory management issues. This should pose a substantial barrier to hackers looking to exploit vulnerabilities in memory management.
The Windows Phone 7 SDK creates apps each with their own private chamber in which to operate on the phone. Based on a least privilege model, the chamber limits the capabilities and privileges of the app to those it needs in order to function properly.
At installation, the OS checks the manifest and enforces the specific capabilities and privileges the app receives inside its chamber. "The chamber provides isolation and the privileges cannot be changed during runtime. The phone is safe from the application and the applications are safe from malware," says Alan Meeus, senior product manager, the Windows Phone Team.
SSL connections and certificates are more a one-or-the-other-will-do proposition, though having both would be better. After starting out on equal footing there, two SDKs stand out. While the Android SDK boasts a number of named security techniques that protect against high-profile attacks such as buffer-overflows, Windows Phone 7's intuitive, global approach to "chambering" or sandboxing each application should help developers to rest easier at night. Despite all that, vulnerability patches are as certain as the sunrise.