Students, Start-Up Team To Create Android 'Master Key' Patch App 87
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.
Rooted Only (Score:5, Insightful)
Leaves out 99% of the devices out there.
Re: (Score:2)
Not really. Windows XP is still supported. It's XP that will be like legacy Android all over again.
Comment removed (Score:5, Interesting)
ICS needs more RAM than Gingerbread (Score:2)
Re: (Score:2)
Google could stop shipping Gapps on 2.x (Score:2)
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
Re: (Score:2)
Did you mean like what Amazon did (Score:2)
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
Re: (Score:2)
Re: (Score:2)
Note as well that XP legacy computers were a problem for all the case where the computer was part of a critical system. It is arguably far less frequent for smartphones.
patching (Score:2)
Re: (Score:1)
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.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:3)
Which in turn is Google's fault for designing Android to be sold that way. They deliberately choose not to have control over the fragmentation and issues like this.
Re: (Score:2)
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
Re: (Score:1)
Indeed some do. Cyanogenmod is probably the most mature of them. By nature that means they're not always the fastest to new features, but they're reliable and thorough.
Check out the most recent weekly review post on their site; it mentions the security issues brought to light last week and the two point releases in response.
http://www.cyanogenmod.org/blog/this-week-in-cm-july-12-2013
Re: (Score:1)
Hmm. The BlueBox app is reporting that my phone isn't patched even though I'm on 10.1.2...
Another attack vector (Score:4, Interesting)
Looks like a great way for someone to create a fake update and publicize it as a third-party patch. Google needs to make good on do no evil by proactively doing good.
Reviews are showing some problems (Score:5, Informative)
The reviews on the Play store are showing a fairly high possibility of a bootloop. While I'm all for open source and public patches where appropriate, I expect I'll be passing on this one for now.
Odds Are (Score:3, Interesting)
Both sides of his mouth (Score:4, Insightful)
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.
Re: (Score:2)
My Google sold phone gets updates on Day 1.
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.
Re: (Score:2)
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.
Re: (Score:2)
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 (Score:2)
Re: (Score:2)
they aren't wiling to take the risk of bricking the phones.
you have to connect through adb or mitm the play store to exploit it anyways.
Re: (Score:3)
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
Re: (Score:2)
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.
Alternatives are things like cramfs enabled kernels with cramfs packed rom block devices.
Re: (Score:2)
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.
Re: (Score:3)
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, ...
Re: (Score:2)
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?
Re: (Score:2)
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
Re: (Score:2)
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.
Yes they use the existing ones.
Re: (Score:2)
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
Re: (Score:2)
Well, it depends - my machines aren't running any closed source drivers.
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
Re: (Score:2)
Well, it depends - my machines aren't running any closed source drivers.
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
Re: (Score:2)
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
Re: (Score:2)
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
Re: (Score:2)
I certainly wouldn't call them the "ass end" - it depends what you want.
Ok, generally "lowest performance" and worst graphics feature support.
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 believe that highend graphics machines requires tweaking drivers just to make them work then you're clearly doing something wrong.
I'm after the latter - I have absolutely no interest in gaming.
The idea that the only people interested in anything but lowend integrated graphics is gamers is just ignorant.
This certainly isn't my experience - frequently the vendor written Windows drivers are bloatware, unstable with proprietary APIs whilest the reverse engineered Linux drivers are much higher quality.
Which vendor-written ones are "bloatware" with "unstable proprietary APIs" compared to the "much higher quality" Linux drivers?
Except on my machine it does work well, including all of the hardware.
Just like on an openmoko handset or an aava.
Which was pretty much my point - there's a lot of PC hardware out there that does just work perfectly with only open drivers.
And in the end even if
Re: (Score:2)
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
don't let carriers lock phones down or force them (Score:2)
force them to give the unlock codes no questions asked even if you are on a phone payment plan.
Re: (Score:3)
This doesn't solve the actual problem in the handset world, especially with android.
That problem?
Closed source binary drivers for novelty features in specific handsets that are incompatible with newer android builds, due to improved/newer linux kernels being in them.
Take for instance, my horribly crippled, antique android device:
SGH-T839 (Sidekick 4G)
This device runs Froyo, and has been officially abandoned by T-mobile and Samsung for almost 2 years now. It has a 1ghz hummingbird cpu, and approx 512mb of ra
Re: (Score:2)
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
Re: (Score:2)
That'd unlock the SIM card slot, I'm not sure what it would do for getting new software onto the device.
Your fault. (Score:3)
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.
And it's all your fault.
Re: (Score:2)
My device had root and an unlocked loader within hours of purchase.
It has never had a major android upgrade.
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.
Turns out that wasn't the case.
Re: (Score:2)
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.
What's Google's excuse for not patching the N4? (Score:4, Insightful)
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.
What's Google's excuse for not patching my device? No carriers involved, current model, etc.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Like everywhere else, you (the consumer) are not Google's customer.
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
Re: (Score:2)
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
Re: (Score:2)
Are you sure your phone hasn't been patched? My Nexus 7 has, according to https://play.google.com/store/apps/details?id=com.bluebox.labs.onerootscanner [google.com]
Nexus 4, and yes, still vulnerable (Score:2)
Re: (Score:3)
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
In Soviet Russia (Score:1)
Blame the OEMs this time (Score:2)
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.
Vertical Integration hurting Android (Score:2)
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
Re: (Score:2)
I'm not sure what you mean by "vertically integrated" here. Can you elaborate on that?
Re: (Score:2)
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.
Re: (Score:2)
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