Can Chrome learn from iPhone jailbreak flaws?

The recent script kiddy jailbreak  (browser based on attacks on the iPhone 4.0 and 4.1 iOs led me to think can Google Chrome learn their lessons? This joins my other posts on iPhone and Android security and on using Chromium OS

Looks like 2 main vulnerabilities one in PDF then once that is run another in the kernel to breakout of the sandbox and get root access. Also 2 more applications could be affected. At an abstract level though the attack tree it is basically:
  • Get user to run attack (or use iFrame, phishing, malware on legit site, or user chooses to jailbreak etc)
  • Attack exploits vulnerability in software - more often than not now it is companion software like Adobe PDF (although in this case it is Apple written PDF)
  • Exploit code is either in the package or downloaded from the Internet, dials home (exploiting the outbound to open the transaction that accepts any inbound return or opens a port for other malware to connect to)
  • The code runs in the context of a system account or other privileged  account / process
  • Pwned for fun and profit - feel free to steal contact info, monitor calls, call other people etc etc

Security architecture and design improvements:
  • No permanent privileged access - System accounts (e.g. root processes) should not have this level of privilege all the time. These accounts should apply for and gain this privilege (or the privileged is activated to run) for specific pre-defined processes only (these are integrity checked before they are run and stored on a read only volume or firmware). If it is root privilege and not very often required e.g. on phone boot this should prompt the user and require their password e.g. run as or sudo on Linux
  • User notice and approval - Take a leaf from the Android book and if a program ever needs privileged functions require user acceptance. If a program needs access to phone or system functions e.g. contact details explain to the user what this is with a good example e.g. this screensaver is asking to get access to your contacts e.g. and to also get outbound Internet access
  • Shadow OS - Chrome is already talking about use of a shadow read only OS that is integrity checked against the live production. If any unauthorized changes are detected the device auto reboots and restores from known good. Only signed authorized update processes can change the shadow volume to read/write and update it and the official hash
  • Pre-approved profiles - Have a known profile of what the system/root accounts needs to do e.g. if it never needs to communicate over the network don't allow this to occur
  • Detect modifications and tampering - Good Technology, Sybase Aferia, Junos pulse say they are able to detect jailbroken (or modified iOs), why can't Apple or Google do this with Chrome (or licence this technology if they can't). Ultimately Apple in particular will need to integrate these technologies into their native OS if they want to truly break the RIM stranglehold on the corporate market. Chrome should have these from the outset.
  • Firewall and anti-malware - Apple and Google need to get off their high horse and admin they need anti malware and personal firewall on their OS and devices. The only reason there are no real viruses for MAC's are that they were not worth targeting. Now that has changed. There are already viruses for Linux systems - to use a head in the sand this only impacts Windows approach is just stupid and negligent to their user base. E..g. if there was AV even zero day attacks like jailbreak me would only be valid for about a day.

These would be hard on PC's but on a fully controlled device like the iPhone or what with Chrome requiring firmware level install it could be possible. Just some ideas to improve Chrome security architecture that will hopefully reduce the risk or make it a lot harder to "Jailbreak".


  1. I don't know much about the low level workings of either the iPhone IOS or Chrome, but I suspect part of the problem is similar to other mobile OS's. That is that the OS itself does not have the concept of privileged and non privileged access. In an effort to keep the OS light and performant (I know it's not a word!) they skip the entire concept of authentication at the OS layer. Now it might be the case that the OS's you talk about do actually support the concept, however, it's also quite likely that they don't.
    One other note is that typically if a given process needs higher privileges to do something, it will often continue to need the higher privileges to function. Now it might be possible to fork the process and give the children less privileges (think most drop privilege design), however, that wouldn't change the fact that you will need a number of process to run with the high privilege in the first place.

  2. First point: "OS itself does not have the concept of privileged and non privileged access"

    Actually iOs is based on OpenBSD and Chrome OS on a Linux base as well so they most definitely have a concept of privileged and non privileged access. Both OS sandbox their applications, with the Jailbreak me code for iOS4.0.1 and below the writer used a PDF vulnerability and then a kernel vulnerability to defeat the permission levels and sandboxing

    Second point - I don't disagree that some proceses will need the highest privileges to function. My thinking was whether you could design an architecture where these processes only requested this level of privedge when they needed to perform a specific set of pre-defined functions (which was hashed and protected) thereby meaning that they did not have these privileges all of the time. This would in theory stop an attacker being able to run some malicious code they introduced under say the root account even if they were able to get access to this via a buffer overflow or other vulnerability.



Written by