Slashdot Mirror
Fragmentation Leads To Android Insecurities
Rick Zeman writes "The Washington Post writes about how vendor fragmentation leads to security vulnerabilities and other exploits. This situation is '...making the world's most popular mobile operating system more vulnerable than its rivals to hackers, scam artists and a growing universe of malicious software' unlike Apple's iOS which they note has widely available updates several times a year. In light of many companies' Bring Your Own Device initiatives 'You have potentially millions of Androids making their way into the work space, accessing confidential documents,' said Christopher Soghoian, a former Federal Trade Commission technology expert who now works for the American Civil Liberties Union. 'It's like a really dry forest, and it's just waiting for a match.'"
iOS is a single target, get one sploit that works, you know it'll work on all of them. The recent exnyos sploit only worked on some Samsung chips. So.. hackers have more devices to attempt to hack! Though all this is a waste of time if people use non-standard app stores and/or download warez, then what do they really expect?
Waiting for an amusing sig.
Not so long ago niche platforms and disparate architectures were slated to be good BECAUSE they were so diverse it wasn't worth the time to hack them individually...
I also remember a time not so long ago that Microsofties used to complain that the frequency and ease of attacks on public sites was due to their dominance and being a big target. I wonder what Linux admins say now, since they now dominate the data centre?
This tagline was transcoded to result in at least one smirk. If you experience failure to smirk, please consult your Gen
The problem isn't vendor fragmentation. The problem is vendor laziness. If you produce an Android device there is no legitimate why you can't provide regular updates.
If there was either a common hardware platform, like on the PC, where every PC is essentially compatible with every other PC, you could easily update your operating system without the manufacturer of the hardware.
However SoC vendors don't want that, since it would mean that a device maker could easily switch from one SoC to another one. Plus they still use undocumented proprietary hardware in those SoCs, that's why you have binary device driver blobs which are hard to port.
The other problem lies within Google. They should have mandated some sort of "BIOS" which would have allowed any operating system to see what kind of hardware there is. This wouldn't have been more than a few hundred bytes in the flash containing the bootloader. That way you could have a generic operating system image, which would read out that ROM and execute routines found in it to use the hardware and then, perhaps at a later stage, use specialized drivers... just like it's done on the PC.
The sort of fragmentation we currently have in the Android market is simply bad, but a logical consequence from bundling hardware with the operating system. I just hope that one day the Chinese will wake up, and design a common hardware platform allowing the user to boot its own operating system from the SD-card, and even move it from device to device.
Trying to argue about fragmentation with people attacking Android is a losing battle. "Fragmentation" means there's too many different hardware form-factors. No, it means too many vendor-specific UIs. No, it means that we need to support multiple OS versions. No, it means that we can't guarantee what security patches have been applied.
Bah, from where I'm sitting, "fragmentation" means nothing more than "I don't like it" - a way of disparaging choice from those who don't want it.
Just because you're paranoid doesn't mean there isn't an invisible demon about to eat your face
You get one exploit that works against Android Gingerbread, and you've got one that works for 2+ years against the still most popular version, by a large margin.
Linux has huge diversity among its many distributions, and yet it doesn't suffer from the security problems described in the article. So-called "fragmentation" isn't really a valid technical reason for lack of security at all. If a system is designed for security then it will be secure, regardless of the number of its variations.
The real reason why Android is lacking in security is because Google hasn't focused on security. They decided not to include iptables/netfilter (the Linux firewall) as a standard facility in Android, which would have been very easy to do. And they haven't allowed users to block privileges demanded by apps after install. Instead you're offered only a package deal, either let the app do whatever it wants or don't install it, period. Android users are hence pressured into a corner, and the end result is often worse security than they would wish.
Don't blame fragmentation. Instead point a finger at Google designers who seem remarkably disinterested in supporting the Android user's security and privacy requirements.
"The question of whether machines can think is no more interesting than [] whether submarines can swim" - Dijkstra
It is just the customization and vendor disinterest that prevents updates. It is as if Dell, Lenovo, HP, etc added their crapware so deeply into the Windows infrasture that Microsoft's security updates could not be applied and the vendors were not interested in creating or distributing adapted versions.
On the contrary, it is vendor interest that prevents updates.
The first thing to know is that Google does not create Android releases. Google does continuous Android development, and any time after release N.M, but before N.(M+1), or (N+1).0, for new major releases, the code base is called after the current tree version number. When a vendor wants to release a new Android cell phone, there may be parts of the code base they've contributed back for specific chip and peripheral support, but what they do is take a cut of the code base and freeze it. Then they apply patches and finishing touches which don't get integrated back to the main Android code base as part of taking it from the raw, unproductized Android code base to a productized version which can be shipped to customers.
The dirty little secret here is that all productization is done by the device vendors, and not by Google, and that Google itself is basically incapable of productizing an operating system like Android. Instead, they rely on the device vendor to do this, and the device vendor, wanting product differentiation, willingly cooperates, or even insists, on this happening outside of Google.
What that means is that "Android version 4.1" is a meaningless way to compare Android devices with one another, since Samsung's version of 4.1 may not have identical bits with Sony's version of 4.1, since they were most likely cut from different development versions of the source tree, even if they were cut only hours apart.
The bottom line here is that, even with a working security fix back-ported to "Android 4.1" is most likely going to result in a product reintegration, since the patch(es) will have to be rolled forward from the Google release branch of 4.1 (which has no additional changes past the Google release date) to the vendor's version of 4.1, which is a set of patches and productization on top of some code branch somewhere between Google's 4.1 and their 4.2. This is nearly as much effort as developing a new "model 720" phone with COGS-reduced parts, and based on the original "model 710" phone from that same vendor. The team which works on this "improved Android 4.1 for the 710" is a set of people who isn't working on the "model 730". As far as a vendor is concerned, that's spending good money to update a product for previous customers who aren't paying them money for the new improved version of the product, because "the old version is good enough".
The second thing to know is that the carrier marketing model in the U.S. effectively discourages the carrier from updating the OS, even if the handset/tablet manufacturer were willing to integrate the bug fix and provide an update.
In the U.S., a carrier locks you into a 2 year contract, and then offers you a 6 month "early update" to lock you into that carrier again for another two years after 18 months. The upshot of this is that they get to keep the captive user as a subscriber, in trade for a new handset, which is subsidized by the carrier, and the old handset has been fully paid for (and then some) by the monthly bill portion which pays for the "free" handsets in the first place.
The net effect of this is that, if they update an old phone, unless they have a new phone with some compelling new feature(s), the customer is more likely to "ride out" the remaining six months on their contract, and then just switch carriers. The only real compelling features that differentiate one Android phone from another these days are the version of Android they are running. Sometimes there are minor changes in hardware, but frankly, there's usually no hardware change that's compelling enough to get someone to NOT
We know iOS insecure because its jail broken every other week. Ironically done to have similar functionality of Android.