By now, security-conscious IT pros know about the new and improved version of the iOS jailbreaking software, jailbreakme, now with iPad 2 support. It ingeniously exploits a flaw in the iOS PDF display code to, via a buffer overrun attack, load jailbreak code into the root file system of the device. Once rebooted, the hacked code injects itself into the device's startup sequence using the video frame buffer as its temporary scratch memory.
What makes this exploit so nefarious is not only its device-independence (it works on everything from the original iPhone and iPad Touch to the latest iPad 2), but that it uses innocuous-looking PDF files, delivered via the browser using Safari's built-in PDF viewer, as its distribution method. While jailbreakers generally know what they're getting into, the same technique could be used more deviously by those with less wholesome intentions to deliver "modified" PDF files via obfuscated URL shortening and a Twitter or Facebook feed. While the specific PDF vulnerability has not been publicly identified, and the current exploit isn't known to have a malicious payload, the technique could easily be used for more nefarious purposes than jailbreaking. As a posting on F-Secure's blog points out:
So, although the intent and results of this hack appear to be relatively benign (and reversible), it's still interesting and disturbing because of its technique -- an app running in user space that can inject code into the device's root file system -- and distribution method -- untethered, wireless browsing to a site with the malicious payload versus Apple's standard method for kernel modifications using iTunes and DFU (device firmware update) mode. Of course, Apple promises a patch for this iOS vulnerability, and based on the last time this PDF vulnerability was exploited (August), the fix will likely be quick in coming, perhaps even by the time you read this.
However, this incident raises a larger issue: What should Apple's (or any mobile device vendor's) strategy be toward security? While iOS incorporates many security techniques not seen in the more open PC environment, including a tightly controlled, curated application ecosystem, this incident clearly demonstrates that it's still not immune to serious security holes. Since we're on the third iteration of this particular exploit, I'm wondering if Apple should do more than play whack-a-mole, issuing iOS patches in response to the latest hack.
Sure, the reactive approach is the norm; witness Microsoft's monthly Patch Tuesday releases to fix the endless stream of discovered Windows holes. But Apple's tight control of the iOS application ecosystem also means it's impossible for third parties to produce antivirus/anti-malware software. There are too many restrictions on what legitimate applications can do within iOS, such as scanning another app's memory or local storage, to allow traditional A/V techniques to work.
Of course, this is a blessing and a curse. Such tight control over an application's access to the rest of the system is a cornerstone of the iOS security model. However, it also means the security onus is entirely on Apple. Android's more open approach enables third-party security apps, such as AVG, Lookout, and Symantec, to augment native runtime protections built in to the OS with code-scanning and data-protecting features that arguably can catch (or mitigate) zero-day -- read: unpatched -- exploits. Still, I'm not sure which model will work best on mobile devices: Apple's tightly controlled, IBM-mainframe approach or Android's freewheeling, all-comers, Microsoft PC-like paradigm.
0 komentar:
Post a Comment