Posted
by
Soulskill
on Tuesday July 16, 2013 @09:08PM
from the exercise-for-the-readers dept.

chicksdaddy writes "The saga of the application-signing flaw affecting Google's Android mobile phones took another turn Tuesday when a Silicon Valley startup teamed with graduate students from Northeastern University in Boston to offer their own fix-it tool for hundreds of millions of Android phones that have been left without access to Google's official patch. Duo Security announced the availability of an Android utility dubbed 'ReKey' on Tuesday. The tool allows users to patch the so-called 'Master Key' vulnerability on Android devices, even in the absence of a security update from Android handset makers and carriers who service the phones, according to a post on the Duo Security blog. Jon Oberheide, the CTO of Duo Security, said that ReKey provides an in-memory patch for the master key vulnerability, dynamically instrumenting the Dalvik bytecode routines where the vulnerability originates, patching it in-memory. Oberheide said that ReKey will also 'hook' (or monitor) those routines to notify you if any malicious applications attempt to exploit the vulnerability. Despite the availability of a patch since March, many Android users remain vulnerable to attacks that take advantage of the application signing flaw. That is because Android handset makers have been slow to issue updates for their handsets. For platforms (HTC and Samsung) that have been patched, carriers delayed the rollout to customers further. 'The security of Android devices worldwide is paralyzed by the slow patching practices of mobile carriers and other parties in the Android ecosystem,' said Oberheide. However, the fragmentation of the Android ecosystem is significant enough that it is no longer feasible for Google to take over responsibility for distributing patches. Third parties may need to step in to fill the void."
A related article makes the case that the release of the Master Key vulnerability started an important conversation within the open source community.

Exactly, you can say a lot of shit about MSFT but the length of support is just incredible. Compare this with Android where many of the devices being sold today will NEVER get a patch or update, hell go to Walmart.com and look under Android to see how many 2.x devices they are selling RIGHT NOW and you just know those devices are never gonna see this patch or any other patch for that matter.

Like it or not, and personally i think Google made a pretty slick OS, but Android is by far the most fragmented and least supported of the mobile OSes. If guys want to know what a downside to FOSS is here ya go, because Google can't control the code they can't make the OEMs go with the safer latest and greatest, nor patch older versions, hell Google can't even get them to stop putting out 2.x devices.

"As long as Windows 8 requires a GB of RAM there will still be Win98 devices"...see the problem friend? Google doesn't still support 2.x last i checked, so NO updates, NO patches, it would be NO different than selling Win9X today only much worse as the malware guys no longer target win9X but there is enough 2.x devices out there to make it a juicy target.

Again this is a downside of FOSS, whereas MSFT can refuse to sell licenses and thus get old no longer supported OSes out of the channel Google on the oth

Google on the other hand has absolutely zero say when it comes to the OEMs

"Absolutely zero" is strong language. Google Play Store is not FOSS, and Google could sue any OEM that ships an infringing copy of Google Play Store on a device. Google licenses the Gapps only for distribution as part of the preload on devices that pass the tests for conformance to a particular Android version's Compatibility Definition Document. To get 2.x (and the underpowered hardware that needs 2.x) out of the channel, Google could declare a date after which Gapps are no longer available on new 2.x phon

Think the OEMs give a rat's ass about a store that makes GOOGLE money but NOT them? Oh please, they all run their OWN apps stores where THEY get the appmoney AND the datamining money, in fact i can't remember ever seeing one of the 1.x or 2.x devices even having the Google store, they all have an ersatz being run on a server somewhere in Hong Kong.

So I'm sorry friend but this is one of the weaknesses of FOSS, open source means you can't say shit about that source and what is done with it, again look at pl

Think the OEMs give a rat's ass about a store that makes GOOGLE money but NOT them?

Say an OEM decides to go this route of shipping a device running outdated AOSP and its own store. How would it go about attracting Android application developers to its own store? In order to get its own 30% cut, such an OEM would have to spend time==money hosting, curating, and promoting its own store. I seem to remember only Amazon making a wholehearted effort at setting up its own store for the Kindle Fire. Other 1.x/2.x devices without the Gapps, such as seventh and eighth generation Archos tablets, end

Uhhh...you have NEVER worked retail have your friend? I hate to break the news to ya but they don't give a wet fart about "attracting app developers" all they care about is having a few brand name apps, your angry birds and your cut the rope, hell since its being run from a server in Hong Kong it wouldn't surprise me if they are just using pirated versions, no copyright police to worry about over there.

But please do NOT take MY word for it, you have a Walmart near you, yes? Go in and look for yourself, th

The patching thing is a bit of a joke. If I had an android phone, I'd want an equivalent to Ubuntu to provide a 3rd-party OS with regular updates. I think 3rd-party Android distributions are out there, do they handle security updates well?

Yes. I run a flavor of the AOSP (android open source project) and was patched virtually first day the code was given out by google. I'd recommend a nightly build for security, even if the dailies add new functional faux pas at points. they usually get fixed, but documented security stuff is fixed pretty quick. even if say google is informed, doesnt release code - if the android community at large is informed, it gets pushed into the larger releases pretty quick.

yea, i use aokp and i love it. that being said, it isnt google's fault that they cant get the patches out to everyone as soon as they create them. the problem lies with the cell phone distributors who consistently take forever to install all their adware and crapware onto each patch before deployment. it takes at&t over a year to release the operating systems on their phones, whereas a rooted phone can get it instantly.

The problem with the Galaxy Nexus is that Samsung are in charge of a updates for a lot of the variants of this phone. There has been some debate on whether it should be called a true "nexus" phone at all.

yea, i use aokp and i love it. that being said, it isnt google's fault that they cant get the patches out to everyone as soon as they create them. the problem lies with the cell phone distributors who consistently take forever to install all their adware and crapware onto each patch before deployment. it takes at&t over a year to release the operating systems on their phones, whereas a rooted phone can get it instantly.

Except, my "adware and crapware" laden Samsung Galaxy S3 from Verizon was patched a few days after the story was in the news, without me rooting or romming or anything. Nexus devices that get updates straight from Google (who has publicized the patched code) have not been patched via update yet. Phones running totally custom ROMs (which is very different from rooting, fyi) can obviously get the update whenever the ROM maintainer releases a patch, or if their ROM isn't maintained (a lot aren't) they can swit

'The security of Android devices worldwide is paralyzed by the slow patching practices of mobile carriers and other parties in the Android ecosystem,' said Oberheide. However, the fragmentation of the Android ecosystem is significant enough that it is no longer feasible for Google to take over responsibility for distributing patches. Third parties may need to step in to fill the void."

But, but, if it's no longer feasible for Google to provide patches, how come he says his company, with vastly fewer resources, can do it?

It stands to reason that if Google can't patch your phone because of "fragmentation of the ecosystem," nobody else can either. That makes me not at all anxious to install his patch.

As far as I can tell, your phone that gets updates on Day 1 doesn't have an update that fixes this particular issue. I have two Nexus devices, and as far as I can tell the only one not vulnerable to this issue is the one running Cyanogenmod.

I have a (by current standards ancient) Galaxy S3 from Verizon running all provided software and it was patched within a few days of the first news article (without an OS level update). How is it that Nexus devices aren't? This whole thing stinks of smoke and mirrors, and mostly from the fearmongers who "discovered" this issue.

Citation for the security release? I'm genuinely interested in this - I've yet to hear of any vendor updates for this issue that fix the root cause, but it isn't like they usually reference CVE's/etc so it isn't easy to tell when vulnerabilities are patched. The CVE for this issue is CVE-2013-4787.

All I know for sure (based on numerous owner accounts) is that the S3 and S4 across all networks got patches "from Samsung" very shortly after the vulnerability went public.

The question is whether those patches had anything to do with this vulnerability. I did find mention of S3 patches a few months ago, but no mention of this issue.

Obviously the solution is for phone OS vendors to do what every PC OS vendor does and have official release notes including CVE references, and then it is easy to know what vulnerabilities do and don't apply to any system. It is amazing how little care is given to security updates on mobile devices.

Blame the carriers for charging as much per month for service on an unsubsidized phone as on a contract. Blame the CDMA2000 carriers for not using CSIM and refusing to activate phones they didn't sell.

With desktop Windows and Linux, the latest version works on all (powerful enough) computers. Why can't it be this way on Android?

It is that way on Android, you can install vanilla Android from AOSP on just about any device that's powerful enough if the bootloader is not locked by the OEM. Problem - as I understand it - is most devices aren't powerful enough to run the latest version. Of course this is compounded by fragmentation within versions, for every version of Android most OEMs create their own version of that. That is why the Galaxy S didn't get an official ICS update, the official Android versions for it were forked versions

Personally, for devices with crippled rom capacity, I would be willing to have the basic kernel image with the sdcard and FS drivers in the rom, and have the rest of the android platform in a filesystem on the sdcard, mounted in with symbolic links.

Also, for devices with low RAM, tell the user it will run like ass, then make a build that loads zram, puts a swap partition on the/dev/zram0 device, then turns swap on. That can cut ram consumption by system daemons by nearly 50%, if the block device is sized sensibly, ans swappiness is set sanely. Because zram is a compressed ramdisk block device, the swap operations just munch a bit of CPU, and are quite speedy. Turning it on is commonplace in community rom builds.

It is that way on Android, you can install vanilla Android from AOSP on just about any device that's powerful enough if the bootloader is not locked by the OEM. Problem - as I understand it - is most devices aren't powerful enough to run the latest version.

Most devices require closed source binary blobs to drive much of the hardware. So yes, you can install AOSP on any phone so long as you don't mind not having a working cellular radio, wifi, gps, screen, bluetooth,...

Most devices require closed source binary blobs to drive much of the hardware. So yes, you can install AOSP on any phone so long as you don't mind not having a working cellular radio, wifi, gps, screen, bluetooth,...

So explain how you believe all the custom android versions, ubuntu touch, firefox os run on various devices, or are you suggesting they only run on hardware that has fully open source drivers and no binary blobs?

Most devices require closed source binary blobs to drive much of the hardware. So yes, you can install AOSP on any phone so long as you don't mind not having a working cellular radio, wifi, gps, screen, bluetooth,...

So explain how you believe all the custom android versions, ubuntu touch, firefox os run on various devices, or are you suggesting they only run on hardware that has fully open source drivers and no binary blobs?

The custom android versions, such as Cyanogenmod, bundle the binary blobs for popular devices (which were extracted from the official images). Go try and run that stuff on a less popular device and you'll struggle. For example, the Samsung Captivate Glide was stuck with Gingerbread until Samsung released an ICS upgrade because the binary blobs in Gingerbread aren't compatible with ICS and Jellybean. Even now, there are various problems with the third party Captivate Glide firmwares due to bugs in the bin

For example, the Samsung Captivate Glide was stuck with Gingerbread until Samsung released an ICS upgrade because the binary blobs in Gingerbread aren't compatible with ICS and Jellybean.

Which is exactly the same as with desktop Windows and Linux [slashdot.org], if you change the driver model and the manufacturer doesn't provide drivers then you're stuck whether it's desktop or mobile. If you don't change the driver model (like ICS->JB) then you're probably fine, again like on the desktop. Mobile is no different.

I have no experience of Ubuntu Touch and Firefox OS - I assume they either use the existing Android binary blobs, or only run on an extremely small number of devices.

For example, the Samsung Captivate Glide was stuck with Gingerbread until Samsung released an ICS upgrade because the binary blobs in Gingerbread aren't compatible with ICS and Jellybean.

Which is exactly the same as with desktop Windows and Linux [slashdot.org], if you change the driver model and the manufacturer doesn't provide drivers then you're stuck whether it's desktop or mobile. If you don't change the driver model (like ICS->JB) then you're probably fine, again like on the desktop. Mobile is no different.

Well, it depends - my machines aren't running any closed source drivers. In fact, its pretty easy to buy PC hardware that is entirely supported by open software, whereas the same is not true for mobile phones.

However, what you're saying doesn't really take anything away from my original point - you can't just install a brand new Android on any old phone because you're going to need compatible binary drivers which the vendors won't supply. Similarly, a PC that requires binary drivers also isn't very upgrad

But the fact is performance and stability are rubbish because the drivers are generally just reverse engineered from the hardware, which you could just as easily do on mobile as well but the performance and stability problems are much more obvious on low performance device like them.

In fact, its pretty easy to buy PC hardware that is entirely supported by open software, whereas the same is not true for mobile phones.

Which ones outside of perhaps the Lemote Yeelong?

So no, the problem isn't "the device isn't powerful enough"; the problem is "there are no compatible binary drivers available".

Well no actually, many devices aren't powerful enough, but yes the fact that there are a lack of compatible binary drivers is a problem, and equally a problem on desktops, like i

But the fact is performance and stability are rubbish because the drivers are generally just reverse engineered from the hardware, which you could just as easily do on mobile as well but the performance and stability problems are much more obvious on low performance device like them.

Not really. The drivers are frequently written by the hardware vendor in an official capacity. For example, my graphics and wifi drivers were written by Intel - the same people who made the graphics and wifi hardware.

Also, I'm going to go with [citation needed] WRT the idea that reverse engineered drivers are unstable - in my experience, a lot of the reverse engineered Linux drivers have been of higher quality than the official Windows drivers from the vendors. Sure, sometimes reverse engineered drivers

Not really. The drivers are frequently written by the hardware vendor in an official capacity. For example, my graphics and wifi drivers were written by Intel - the same people who made the graphics and wifi hardware.

Outside of Intel, most of the hardware vendors don't do open source drivers and realistically intel graphics is the ass-end of desktop graphics hardware.

Also, I'm going to go with [citation needed] WRT the idea that reverse engineered drivers are unstable - in my experience, a lot of the reverse engineered Linux drivers have been of higher quality than the official Windows drivers from the vendors.

nVidia is prime example, they are unstable and lag behind in OpenGL support.

Sure, sometimes reverse engineered drivers aren't as good, but I think the door swings both ways on this and you can't just equate "reverse engineered" with "rubbish" and "official" with "excellent".

I didn't equate "official" with "excellent", but obviously reverse engineered drivers by their very nature are going to be behind the official ones in features, performance and stability.

Well, my crappy Acer Travelmate laptop is entirely supported by open drivers (ok, there is closed firmware running on some of the hardware, but I'm talking about stuff running on the CPU that has to be integrated into the OS in such a way as to prevent arbitrary OS upgrades without the vendor's help). I can install Fedora on that machine and it Just Works.

You can do that on just about any machine, it just doesn't work well and hardware support is mos

Outside of Intel, most of the hardware vendors don't do open source drivers and realistically intel graphics is the ass-end of desktop graphics hardware.

I certainly wouldn't call them the "ass end" - it depends what you want. If you want a top of the line gaming machine that you have to fart around with tweaking drivers to make them work, etc. all the time then Intel isn't for you. If you just want a machine that can run a modern desktop and keeps working with no farting around then Intel hardware is excellent. I'm after the latter - I have absolutely no interest in gaming. Whilst PC gamers are a significant market segment, they are certainly not the ma

If you believe that highend graphics machines requires tweaking drivers just to make them work then you're clearly doing something wrong.

I used to use nVidia graphics cards before Intel appeared on the scene - I had far too many incidents of upgrading the kernel, or Xorg, etc. and discovering that the drivers no longer worked, then having to roll back the upgrade and wait for 6 months before nVidia got their finger out. Too many incidents of nVidia releasing broken drivers resulting in an upgrade breaking some functionality I was using. Too many bugs in the drivers that many people on the nVidia forums were reporting to be met with absolut

Welcome to the mobile phone handset business model. This was the business model for these suppliers long before Android came along, do you really think they are going to change now? Instead of fixing older handsets they want to release new variants every few months to tempt the unwary with a new bright shiny thing.

The only company doing anything different, no matter how much Slashdot hate them, is Apple. The limited hardware targets they have to deal with allows them to provide longer support and its someth

And by you, I mean all you people who don't merely tolerate the behavior of the cellular phone companies, but actually encourage it by giving them silly amounts of money every month.

It's YOUR DEVICE. We've been down this goddamn road before. Nobody remembers Ma Bell? Nobody remembers Ma Bell owning all devices connected to their precious network? Nobody remembers what a debacle that was? How has this been allowed to arise again?

A smartphone is a stupid name for a pocket computer. And apparently, thanks to the cellular companies, it's going to behave just as badly as a desktop computer of yesteryear. It's like every Windows 98 machine ever shipped was connected to the modern internet yesterday. Madness.

Neither the foss community, the rom hack community, the carrier, nor the handset maker have released such a rom.

At the time, the device was comparable hardware wise to early galaxy handsets. It looked for all the world like the community would be able to support it with little effort as a windfall from supporting galaxy.

It's your device when you drop it on the ground or it gets messed up by a bad update pushed by the telco, or it simply breaks after 2 years due to intentionally shoddy manufacture. It's their device when you want to root it or run some software they have not blessed via their app store or signing system, or want to transfer the device to another carrier.

It's the worst of both worlds for the consumer. And we are letting them do it to us via their uncompetitive practices and lock-in contracts.

That is because Android handset makers have been slow to issue updates for their handsets.

I have a Google Nexus 4, supposedly gets all the updates right away, first to get new versions of Android, etc. I haven't seen an update since I bought the phone 6+ months ago. Samsung has apparently patched their phones; Google announced a code fix months ago.

Yeah - same here - and never mind that the latest version of Android on my Galaxy Nexus made Bluetooth inoperable in my car too. Google has hundreds of bug reports, but are yet to offer a fix or even acknowledge that there is a problem.
Sadly Google are letting the very people down they should be giving most attention: The early adopters and Android enthusiasts.

They would honestly rather sell the devices to third parties who will support them and review/push patches and updates. The person selling the device for $100 is not incentivized to provide any support beyond what's required by law. Google charges $200 because you have higher expectations of them, and they are more visible. Samsung, ASUS, HTC, Sony, and the other big-name competitors in the tablet and phone markets can get away with charg

A couple years ago an update merged the navigation volume control into the audio output volume control. Now it is impossible to use the device for navigation and playing music at the same time. The navigation volume is 10% of the music volume and there is no way to change it. There are hundreds of bug reports and google just doesn't care.

Not that they have ever cared about bug reports on their products. You and I are simply not their customer, in Google's eyes listening to us can only cost them money and no

The last major Android update applied to Nexus phones was 4.2.2, which rolled out [cnet.com] in Februrary. If you haven't gotten an update in six months, something is wrong with your setup. My Nexus phone has also gotten multiple revamps to various Play applications in the last few months, which was most noticeable to me in a complete redesign of the Play Music application. The last update there I know of was a month ago [engadget.com]. I'm not certain what form (if any) the fix for this exploit has been pushed to the phones yet

Whilst it's common (and often justified) to have a pop at the carriers for delaying or preventing updates to devices, it's worth pointing out that I've got access to a whole range of Android devices direct from a number of different OEMs and not a single one of them has yet received an OTA update to fix this vulnerability.

The carriers may still slow down this process, but it's already going slow enough with just the OEMs involved.

Thought I'd point out that it's the vertical integration design of Android that has led to this carrier conundrum in which updates and upgrades are forced to go through the carriers, but the carriers are focused on new sales not maintaining old hardware. So the engineering resources they're willing to invest are minimal, leaving users out in the cold.

This is something that's of interest to me in the design of Firefox OS, which completely separates out the the Linux kernel, and the two layers on top of that

It's a standard term. It means that several components in the chain are all controlled by one company. Pretty much all smartphones are vertically integrated - Apple make the iPhone and the OS and control both. Samsung make the Galaxy and also control distribution of the Android software on it. If they also make the components, or just exert close control over the production of them, then it's even more vertically integrated.

Sorry if the term was used in a confusing way.The idea being communicated was that the different layers of Android (kernel, libraries, Dalvik, etc) are implemented in a way such that they cannot be separately updated. (Probably my understanding of the stack is flawed, I had been thinking that the code was perhaps not cleanly separate in the layers - hence the "vertical integration" idea.)

Either way, the point stands that Android cannot be updated piecemeal, thereby relying solely on carriers, greatly hurti