4 ms·

I linked to our research page, right? http://www.trailofbits.com/resources/mobile_eip_2.pdf http://www.trailofbits.com/resources/mobile_eip_2.pdf http://techc

by dguido 14y ago

I linked to our research page, right? http://www.trailofbits.com/resources/mobile_eip_2.pdf http://www.trailofbits.com/resources/mobile_eip_2.pdf http://techchannel.att.com/play-video.cfm/2013/1/8/Conference-TV-CSAW-THREADS-2012-iOS-Jailbreak-Analysis http://techchannel.att.com/play-video.cfm/2013/1/8/Conferenc... http://techchannel.att.com/play-video.cfm/2011/7/14/Conference-TV-SOURCE-Boston:-Attacker-Math-101 http://techchannel.att.com/play-video.cfm/2011/7/14/Conferen... If you think that Android has a "deeply secure design", than then you probably want to start at the top. Android sits somewhere between "gift to hackers" and "Windows XP". Phil Schiller's tweet was pointing out the consequences of this and how it shows up in successful attacks performed against the Android platform. F-Secure, even though they're an AV firm, does good work once in a while :-). http://www.f-secure.com/static/doc/labs_global/Research/Mobile%20Threat%20Report%20Q4%202012.pdf http://www.f-secure.com/static/doc/labs_global/Research/Mobi... EDIT: I'll give you a few hints. First, Android hasn't solved the updating problem. It's getting better but at far too slow a rate. Every day, hundreds of thousands more devices that takes month to years to patch are entering the market. Furthermore, poor patch management by OEMs and carriers mean that sometimes they think they've patched when they've really rolled back updates. They do this unknowingly because their software deployment processes are abysmal. See http://www.xray.io http://www.xray.io for more info. Second, Android exploit mitigations are very, very weak. It lacks code-signing, one of the strongest mitigations available (just go ask an iOS jailbreaker). Apps have access to a shell. The Linux kernel is full of infoleaks that make kernel ASLR nearly useless. App Permissions, though many people think they help with this problem, actually have nearly no effect whatsoever on the ability to root/jailbreak/privilege escalate on Android. This is what I meant by "blaming users" for security problems, since so many people fall back on "educating" people not to allow apps with certain permissions even though, ironically, it does nothing. End effect: even if Android could patch, rooters will write new exploits when they need them, as they need them. It's getting harder, but it's nowhere near where it needs to be and we're on version 4 now. Third, Bouncer has a severely limited ability to impact this problem. Due to the lack of code signing and the overall architecture of Android, Bouncer can't ensure that the app that it scans is the app that runs on the phone. Apps can dynamically update their own code at runtime. Bouncer appears to rely principally on dynamic, rather than static, verification leading to tricks you can play with timers and environment detection (these attacks have been proven). Further, what about third party appstores? There are dozens out there and you can't just say that they're all second-class (third?) citizens that deserve to get 0wned. 3rd-party appstores are supposed to be a key feature for Android, but they're unsupported entirely by these controls. If you wanted to develop a mobile/embedded platform to bring a new generation of users onto the web and into your customer base, you should have spent about 5 minutes figuring out how to do it without opening them up to harm. Android is the way it is because it wasn't believed these design features (aka safety) couldn't be included in the beginning.

hhw 14y ago
Firstly, the updating problem is a distribution flaw, not a design flaw. The carriers are to blame for that. Secondly, code-signing is a very restrictive approach and is hardly without tradeoffs. If you're going to use iOS as an example, it strongly discourages casual development for a slew of reasons, and there are countless examples of Apple rejecting apps for arbitrary reasons, far beyond issues of malware. Your third point is really only an extension of your second. Maybe you don't personally feel you've had to give anything up for the security that iOS affords, but it's disingenuous to assert that there aren't any tradeoffs at all. Android's more open approach is more true to its open source roots. For it to be different than iOS gives us choice, which is a good thing.
- dguido 14y ago
  The updating problem is a design flaw they knew they would have to deal with and that they did nothing about until version 4, when they started trying to separate core functionality out into apps. That's not acceptable. Code signing can be implemented while still allowing for casual development. See my comment above about the hardware switch on ChromeOS devices. My third point is regarding how the architecture of the platform complicates the ability to analyze apps that run on it for malicious behavior. The NDK, the access to the Linux kernel, and a strategy based around dynamic analysis were all design choices that impacted that. I understand that Android wants to be more open than iOS but you're making the same mistakes the Android team did. Namely that there's no way to deploy the same or similar security improvements without sacrificing something else. It's just not true.
barrkel 14y ago
If Android didn't have side-loading, the capability of having third-party app stores, and access to the shell (to the point of being able to run a terminal), I would likely not be using it. The more PC-like it is, the more usable it is to me, in the medium / longer term, as devices in tablet form factor replace mobile PC use cases.
- dguido 14y ago
  There are safe ways to enable access to it. Take ChromeOS for example, which has a hardware switch on the outside of the device that "jailbreaks" it and allows access to these features. Lack of such creativity by the Android team with regard to security has had a major impact on their current state.

by dguido 14y ago

hhw 14y ago

Firstly, the updating problem is a distribution flaw, not a design flaw. The carriers are to blame for that. Secondly, code-signing is a very restrictive approach and is hardly without tradeoffs. If you're going to use iOS as an example, it strongly discourages casual development for a slew of reasons, and there are countless examples of Apple rejecting apps for arbitrary reasons, far beyond issues of malware. Your third point is really only an extension of your second. Maybe you don't personally feel you've had to give anything up for the security that iOS affords, but it's disingenuous to assert that there aren't any tradeoffs at all. Android's more open approach is more true to its open source roots. For it to be different than iOS gives us choice, which is a good thing.

dguido 14y ago
The updating problem is a design flaw they knew they would have to deal with and that they did nothing about until version 4, when they started trying to separate core functionality out into apps. That's not acceptable. Code signing can be implemented while still allowing for casual development. See my comment above about the hardware switch on ChromeOS devices. My third point is regarding how the architecture of the platform complicates the ability to analyze apps that run on it for malicious behavior. The NDK, the access to the Linux kernel, and a strategy based around dynamic analysis were all design choices that impacted that. I understand that Android wants to be more open than iOS but you're making the same mistakes the Android team did. Namely that there's no way to deploy the same or similar security improvements without sacrificing something else. It's just not true.

barrkel 14y ago

If Android didn't have side-loading, the capability of having third-party app stores, and access to the shell (to the point of being able to run a terminal), I would likely not be using it. The more PC-like it is, the more usable it is to me, in the medium / longer term, as devices in tablet form factor replace mobile PC use cases.

dguido 14y ago
There are safe ways to enable access to it. Take ChromeOS for example, which has a hardware switch on the outside of the device that "jailbreaks" it and allows access to these features. Lack of such creativity by the Android team with regard to security has had a major impact on their current state.