Slashdot Mirror
Android Master Key Vulnerability Checker Now Live
darthcamaro writes "Last week, Rain Forrest Puppy (aka Jeff Forristal) first disclosed the initial public report about an Android Master Key flaw. Code was released earlier this week for attackers to exploit the flaw — but what about users? Google has claimed that it has patched the issue but how do you know if your phone/carrier is safe? Forristal's company now has an app for that. But even if your phone is not patched, don't be too worried that risks are limited if you still to a 'safe' app store like Google Play. 'The only way an Android user can be attacked via this master key flaw is if they download a vulnerable application.
"It all comes down to where you get your applications from," Forristal said.'"
That most phones that are "in the wild" will probably never receive this patch unless they are current flagship devices. That said, do not download things from untrusted sources! That goes for not only smart phones, but computers as well!
hey!
For people who are stuck with vulnerable phones it should be possible for an app to scan the .apk you are considering side-loading and checking if it is a trojan using this particular vulnerability.
When information is power, privacy is freedom.
I have no idea what the mentioned 'master key' is supposed to be.
AFAIK the actual exploit is using duplicate filenames which aren't checked against hashes upon installation of apk...
I'm not sure if this is still true, but I do know that last week the Play store was still using HTTP downloads for the actual APK files instead of HTTPS (even though the API calls do use HTTPS). As such, even downloads from Play may be susceptible to man-in-the-middle attacks. I can't possibly explain it better than this group of comments:
http://it.slashdot.org/comments.pl?sid=3950207&cid=44220885
I'm not saying it's likely - but it doesn't seem impossible either. Seeing as it will be a long time before the average Android user will be running a phone with this patch, I would call "crisis averted" too soon. Of course, we don't know if the complete HTTP download is still verified with checksum gotten from the HTTPS API, but somethow I doubt it.
In some strange way Google is having the cake (open and competing app stores, instead of the total lock down on the Apple-iOS side of things) and is eating it too (its app store is less vulnerable than its competition due to its own bugs).
In the long run, having reliable and competent competition is what going to create lasting value to the customers, keep Google on its toes and keep it nimble. So if Google is really not evil and if it is interested in long term success, it should not take short cuts to maintain an edge over competing app stores. Hope it does.
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
And what prevents you from doing this with any executable file format, be it APK, EXE, ELF or JAR? Diassemblers, unpackers and resource editors exist for all of those file formats. If you can run it, you can edit it, unless the format/architecture is totally undocumented.
For those running Cyanogenmod this has been patched in 10.1.1.
If it's about the appstore you use, then F-droid has a leg up. Unlike Google's, everything on F-Droid has had human eyes look at what it does.
We should learn what we need to know about issues, before we decide what we need to feel about them.
The signing isn't meant to stop that, it's meant to stop updates to installed apps being replaced by malware. Re-signing won't let you update an installed app, you have to trick the user into uninstalling first. Which usefully can't be done for system apps by non-rooted users. Can't directly be done by any user.
Ultimately all signing does is verify that your still dealing with the packager of the existing installed copy. The chain of trust still depends on trusting the first install, with this bug you're now reliant on checking each update hasn't been tampered with as well as checking the signature is the same. Good thing its so easy to spot tampering.
A lot of people don't read that.
My co-worker has a taxi company's app. They want full permission for everything. I didn't load it.
https://play.google.com/store/apps/details?id=com.appbuilder.u66459p124918
Same with the Cineplex app. Way too many permissions for something that's just showing a ticket:
https://play.google.com/store/apps/details?id=com.fivemobile.cineplex&hl=en
---
ECHELON is a government program to find words like bomb, jihad, plutonium, assassinate, and anarchy.
> Simple enough, if your app knows what it needs to do, there is no need for "Full Network Access". I smell scam app.
Or an app that, like 98% of the free apps in Android Market, embeds Google's ads in the app. Then it needs full network access, coarse location, and read phone state & identity, among other things. It's the killer flaw in Android's permissions system... to serve ads from any common ad network, you have to practically give the app complete access to everything.
Instead of embedding ad-handling into apps, ad-supported apps should require the installation of a content-provider app for the ad network (common to all apps using it) as a prerequisite, register itself with Android as an ad service provider, then allow apps declaring a permission like "Communicate with Advertising Service" to blindly embed content from that service provider into the app as a black box that the app itself can't influence or communicate with (so an app can't try to leak user information back to its own servers using the ad network as a backdoor). THEN, we could have apps with no app-related need to access the internet that declared only "Communicate with Advertising Service" as a permission, and a separate set of permissions for the Android-firewalled adserver content provider that would be unable to communicate directly with the ad-displaying app.
I agree that an Android smartphone is a personal computer. But when you plug your smartphone into an HDMI cable, how many windows can you keep open on the screen at once? Like you, I own an Android device and an Ubuntu netbook, in my case a Dell Inspiron mini 1012. When I'm programming on my netbook while riding the bus to and from work, I routinely split the screen down the middle to see the source code on the left and the output, another source code file, or documentation on the right. I imagine that even non-programmers find it useful to see both the document you're referring to and the document you're writing. But Google has strongly resisted any sort of split-screen feature in stock Android.
The chain of trust still depends on trusting the first install
There are ways to establish trust for the first install even if it is not from Google Play Store. For example, if I download the APK of VLC from https://www.videolan.org/ then I'm piggybacking on the SSL CA infrastructure, which assures me of one of the following:
How likely are the scenarios other than A?
People who choose not to install can always contact the application's developer privately.
Most of the permissions on the Cineplex app are perfectly justifiable. "Full network access" is needed to contact the payment processor and venue to buy your ticket. "Add or modify calendar events" is to remind you when the event for which you bought a ticket is about to occur. "Take pictures and videos" appears to be needed for scanning barcodes on tickets and related documents. And perhaps "precise location" is used for getting directions to the venue. My only suggestion is to make Google Play Store require the application publisher to add an explicit rationale for each permission it uses.
According to this post, using any of the anti-features will hide an application from most users. How should one fund the development of, say, a video game to be distributed to users who have switched to F-Droid without putting in ads (which requires the "Ads" anti-feature) or charging for mission packs after the first (which requires the "NonFreeAdd" anti-feature)?