6 ms·

You manage to say a lot while saying absolutely nothing of value. That sounds harsh, but seriously thus far you've said that Andy Rubin is to blame for <somethi

You manage to say a lot while saying absolutely nothing of value. That sounds harsh, but seriously thus far you've said that Andy Rubin is to blame for <something vague and unsubstantiated> because <something vague and unsubstantiated>, and Android has <some unstated fundamental security gap> versus <some other alternative>. I don't think I've ever read such an absolutely and completely unsupported comment chain that wasn't sitting deep in negative territory on HN. And seriously, the nonsense tweet by Schiller (who would have known that Apple would toss barbs Android's way?) is why you think Rubin moved on? Give me a break. Android has a deeply secure design that runs each process as isolated, low-privilege users, needing to request services after passing through fine grained permissions. Do you contest this? Architecturally Android is much more secure than iOS. The only issues remaining are getting security updates out quickly, though in actual practice this has proven to not be an actual problem (somehow people imagine that if a device is on Gingerbread that also means security patches can't be deployed, I guess having never worked in branched source control systems), and better vetting of the Play store (which will come. The Play store can be both vetted and agile/inclusive. They need to block the bullshit). Neither of this are the apocalyptic "that ship has sailed" nonsense that you are parading.

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

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