Fair enough. However, saying it's somebody else's problem doesn't solve the problem. I see a lot of value in a standard approach. I'm worried this will end up in a bunch of finger pointing and no implemented solutions.
That said, what can we do to raise the bar? (buffer overflows are still possible, but it's significantly harder to do than five years ago). What can we do if we make the assumption that the recovery image hasn't been modified? I admit it's not a perfect solution, but allowing the user to reinstall a full OTA has some benefits. Of course, malware might just neuter the recovery image, or ensure the recovery process recreates a hole. I guess I'm more or less brainstorming (publicly). Given the ability to modify/standardize the underlying device (e.g., SPL), what is the minimum amount of changes that need to be made? (hint, hint for students looking for research problems). I've always seen the concept of a "firmware" as an interesting (and positive) characteristic of smartphones over PCs. I'd love to see discussion regarding this on the mailing list, but if others deem it inappropriate, I'd be happy to continue offline. Thanks, -Will On Mar 2, 2011, at 10:47 AM, Jean-Baptiste Queru wrote: > This is at a level below Android, since anything that Android could do > to keep a backup copy (or something similar) could be compromised in a > similar fashion. The mechanisms involved, if they exist, vary from > manufacturer to manufacturer and even from device to device. > > JBQ > > On Wed, Mar 2, 2011 at 7:37 AM, William Enck <[email protected]> wrote: >> In the wake of all the news regarding the malware in the Android Market, it >> occurred to me that there isn't a good way to *completely* restore a phone >> to factory defaults. >> >> First off, great job to Google for removing the malicious apps quickly. The >> so called "kill switches" in the Android Market and App Store are great >> features for handling exactly this, and obviate a lot of need for antivirus >> software. >> >> At the end of the CNN article that was slashdotted >> (http://www.cnn.com/2011/TECH/mobile/03/02/google.malware.andriod/), the >> author states: >> >> "If you've downloaded one of these apps, it might be best to take your >> device to your carrier and exchange it for a new one, since you can't be >> sure that your device and user information is truly secure." >> >> If my understanding of this malware is correct, it contains an exploit for a >> kernel privilege escalation vulnerability. Sans all the discussion on this >> mailing list regarding forcing OEMs to push security updates, there is still >> the possibility of a zero-day kernel exploit. >> >> Which leads me to the premise of this email: Android lets me wipe all user >> data, i.e., "restore to factory settings", via the user interface (or by >> rebooting to recovery mode), but how do I restore the "system" partition? >> >> Currently, the Google OTA's are frequently patches (which is great to save >> bandwidth). However, these links are only public once someone (e.g., on XDA) >> discovers and posts them. If my understanding of this is correct, there are >> also "full" OTA images out there. >> >> I'm not sure of the best way to achieve this goal, but it would be >> beneficial for a user to restore the system partition to a known state as >> well, without the need to take the phone to a cell provider store. (I recall >> the T-Mobile G2 having an anti-jailbreak mechanism that would potentially >> accomplish at least part of this). >> >> Thoughts? There are some interesting trade-offs when defining the threat >> model for a solution (e.g., do we trust the recovery image hasn't been >> modified). >> >> Thanks, >> -Will >> >> -- >> William Enck >> PhD Researcher >> Department of Computer Science and Engineering >> The Pennsylvania State University >> [email protected] >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Android Security Discussions" group. >> To post to this group, send email to >> [email protected]. >> To unsubscribe from this group, send email to >> [email protected]. >> For more options, visit this group at >> http://groups.google.com/group/android-security-discuss?hl=en. >> >> > > > > -- > Jean-Baptiste M. "JBQ" Queru > Software Engineer, Android Open-Source Project, Google. > > Questions sent directly to me that have no reason for being private > will likely get ignored or forwarded to a public forum with no further > warning. > > -- > You received this message because you are subscribed to the Google Groups > "Android Security Discussions" group. > To post to this group, send email to > [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/android-security-discuss?hl=en. > > -- William Enck PhD Researcher Department of Computer Science and Engineering The Pennsylvania State University [email protected] -- You received this message because you are subscribed to the Google Groups "Android Security Discussions" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/android-security-discuss?hl=en.
