Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Code Released To Exploit Android App Signature Vulnerability

Unknown Lamer posted about a year ago | from the blind-faith-meets-awful-shell-scripts dept.

Android 81

chicksdaddy writes with news of a Proof-of-Concept exploit for the recent Android APK signature vulnerability. From the article: "Pau Oliva Fora, a security researcher for the firm Via Forensics, published a small, proof of concept module on GitHub that exploits the flaw in the way Android verifies the authenticity of signed mobile applications. The flaw was first disclosed last week by Jeff Forristal, the Chief Technology Officer at Bluebox Security, ahead of a presentation at the Black Hat Briefings in August. ... The simple program leverages APKTool, an open source tool for reverse engineering Android applications — decompiling and then recompiling their contents. His script allows a user to select and then decompile a legitimate Android application and then recompile it, creating an altered, 'malicious' APK that will have the same, cryptographic signature as the original file. In an e-mail statement, Google said that a patch for Forristal's vulnerability was provided to Google's OEM and carrier partners in March, and that some (Samsung) have already shipping a patched version of Android to customers. However, that response hasn't been universal — a reflection of Android's fragmented install base."

cancel ×

81 comments

Sorry! There are no comments related to the filter you selected.

I already discovered an infected application (-1)

Anonymous Coward | about a year ago | (#44220713)

It was called "First Post".

So... (4, Insightful)

Microlith (54737) | about a year ago | (#44220723)

This simplifies the generation of a hostile patch but, unless I'm mistaken, this still requires injecting the hostile patch into the Play Store via a trusted account or by convincing some sap to side load it.

third party application stores – especially loosely regulated Android markets in the former Soviet republics and China could be fooled into hosting a malicious application that exploits the APK vulnerability he said.

Gee, 3rd party stores in China and Russia being completely lax on security matters? Go figure.

Re:So... (1)

EEPROMS (889169) | about a year ago | (#44220743)

That was what iIwas thinking, this would only effect people downloading apk files from third party sites or android users downloading files that they think are free version of a $$$ app. If you stick to the Google play app store then you should be fine for now.

Re: So... (1, Insightful)

alen (225700) | about a year ago | (#44220957)

Isn't the magic if android the fact that you can install from third party sources?

Re: So... (4, Informative)

scot4875 (542869) | about a year ago | (#44221103)

Isn't the magic if android the fact that you can install from third party sources?

Sure, that's one very nice thing, but it still doesn't allow you to just be a moron and expect everything to be hunky-dory.

TotallyFreeVersionOfSomePopularGame.apk from a site that's written in mostly Cryillic or Chinese characters? Seems legit!

--Jeremy

Re: So... (0, Troll)

Anonymous Coward | about a year ago | (#44221255)

Android is such a joke but the biggest fail is on slashdot where fantards twist themselves into pretzels to accommodate any bad news.

Re: So... (0)

Anonymous Coward | about a year ago | (#44221269)

Android is such a joke but the biggest fail is on slashdot where fantards twist themselves into pretzels to accommodate any bad news.

That's why I use Windows Phone. =')

Re: So... (0)

smash (1351) | about a year ago | (#44222379)

So you mean end users should check the digital signature to ensure that it is trustworthy? Or that the site they are retrieving from hasn't been hacked and trojaned?

Oh, wait...

Re: So... (2)

damium (615833) | about a year ago | (#44222535)

Digital signatures in android are mostly self signed (you can use a notarized certificate but it has to be issued as valid for 20 years to be on the play store, so good luck). They are for use in verifying updates automatically by the system for installed packages with the same name and for packages requesting to run with shared code or data as another package (upgrade key packages or feature modules for instance).

If you want to verify the source you check the hash or only download from a trusted location. I'm not saying that I agree with the way android is using signatures... it could have been much better... but your signatures in android are not at all the same as a signature for a windows app. Also of note, android has no way of displaying the signature that signed an apk.

More info: http://developer.android.com/tools/publishing/app-signing.html [android.com]

Re: So... (1)

smash (1351) | about a year ago | (#44233831)

So what you're saying is that basically - they're useless? I.e., it's a feature tickbox item that doesn't actually provide any meaningful benefit?

Re: So... (1)

amck (34780) | about a year ago | (#44222951)

Y'know, there may be reasons why I don't want to go to Google Play even though the .apk I'm looking for is free (and 1$ is practically free). I'm not signed into Google Stores because they insist on me handing over just about everything about me.

I'm _not_ giving access to my location, my contacts, etc.

So, I'm on cyanogenmod and F-Droid for free software.

Re: So... (1)

scot4875 (542869) | about a year ago | (#44226853)

So what's your point? You've chosen to use F-Droid to vet your software rather than Google Play; good for you, that seems pretty reasonable and safe.

The whole appeal of sideloading is to give yourself the option to take security into your own hands without Google or Apple or Microsoft babysitting you. You can't demand to get out of the walled garden for a stroll and simultaneously demand that the walled garden keep you safe and then get pissed when you get infected somewhere that the walled garden had no protective influence. You don't get to have your cake and eat it too. You get one or the other; Android is the only handheld software ecosystem that gives you the choice.

--Jeremy

Only if the developer's web site is compromised (1)

tepples (727027) | about a year ago | (#44221433)

What it means is that I can go to the app developer's web site to download the app. For example, if I want VLC, I'll go to VideoLAN to get VLC. The only way this signature vulnerability would affect me is if the app developer's web site is itself compromised.

Re:Only if the developer's web site is compromised (1)

smash (1351) | about a year ago | (#44222387)

Or, a mirror site. Which is not as uncommon as we'd like. Furthermore, without any red flags from say, invalid digital certs, detecting this would require some sort of checksum validation - which if the signature worked would be entirely un-necessary, and is the entire point of using a digital certificate.

This is a major, major flaw - essentially the entire point using of digital signatures on android has been invalidated, unless your device has had this flaw patched.

Belt and suspenders (1)

tepples (727027) | about a year ago | (#44228349)

Furthermore, without any red flags from say, invalid digital certs

Are you talking about an invalid APK signature or an invalid SSL certificate? Because even if the APK signature is successfully forged, forging an HTTPS download would require the attacker to either A. compromise the developer's web server or B. both forge an SSL certificate and MITM the user's Internet connection. I will admit that this is easier with Android 4.x, whose SSL stack supports Server Name Indication, than with Android 2.x, which supports only clear HTTP for sites using name-based virtual hosting.

unless your device has had this flaw patched.

Which is why even 2.x devices are getting "Verify and Install", as I mentioned earlier [slashdot.org] .

Re:So... (1)

tlhIngan (30335) | about a year ago | (#44222315)

That was what iIwas thinking, this would only effect people downloading apk files from third party sites or android users downloading files that they think are free version of a $$$ app. If you stick to the Google play app store then you should be fine for now.

And eliminate useful third party legit sites?

Like say, Amazon App Store? Or Humble Bundle apps?

Sure, you tend to trust these apps as they're from legitimate sites, but are you ABSOLUTELY certain that Amazon and Humble Bundle are checking their files? Google Play only implemented the check when they were told about it, as well. Who knows if they've checked every existing app?

The biggest strength of Android is also its biggest weakness. Once you check the box, Android will not differentiate between Google Play, Amazon App Store, Humble Bundle, Appslib, Random Chinese App Store, etc.

Of course, for the places where there is no Google Play...

Re: So... (4, Informative)

EGSonikku (519478) | about a year ago | (#44220809)

Google PlayStore does NOT use https for actual downloads (check your own WiFi logs). So in theory, if you were connected to an insecure/public WiFi network someone could intercept your download request and replace it with a compromised download using available WiFi auditing tools.

Re: So... (1)

Nerdfest (867930) | about a year ago | (#44220861)

That's good to know, I'd always assumed it was HTTPS.

Re: So... (2)

EGSonikku (519478) | about a year ago | (#44220869)

It's pretty odd, all the PlayStore APIs are done via https, but then the download is http. No idea why they'd do that.

Re: So... (1)

Nerdfest (867930) | about a year ago | (#44220923)

... unless there's another signature verification of the download with signature sent via HTTPS. Seems off though since Google does almost everything via HTTPS these days.

Re: So... (0)

Anonymous Coward | about a year ago | (#44221423)

C'mon, this industry is full of security faux pas. Now that Google Play uses device-specific signing for all of its downloads (so you can't copy APKs between devices) they wrongly assumed that MITM can't happen.

Re: So... (1)

gl4ss (559668) | about a year ago | (#44222839)

... unless there's another signature verification of the download with signature sent via HTTPS. Seems off though since Google does almost everything via HTTPS these days.

it's so that they can do load balancing cheaper. some of the apk downloads can be quite sizey.

Re: So... (1)

smash (1351) | about a year ago | (#44222391)

Performance. HTTP can be cached easily, and doesn't require processing overhead for the encryption. HTTPS not so much.

Does caching mean proxy? (1)

tepples (727027) | about a year ago | (#44226619)

HTTP can be cached easily

Resources served over HTTPS, such as style sheets, scripts, and images, can be cached just as easily by the client as resources served over HTTP. Yes, I'm aware that some web browsers disregard far-future Expires dates and exclude from disk cache so as not to leak HTTPS resources to other applications that can access the same file system. On the other side of a connection, the server can and ideally does cache portions of dynamic pages that seldom change. For example, some of the modules on Phil's Hobby Shop [philshobbyshop.com] are generated once every 20 minutes or so, and the site map [philshobbyshop.com] is updated about once a day.

But neither of those is particularly applicable to downloads of a large (multiple megabytes), relatively static resource such as an APK file. The server's operator can choose to let a CDN close to the client cache large downloads so that the packets making up the download doesn't have to go through quite as many transit links. Or by "caching" are you referring specifically to a transparent proxy operated by the client's ISP?

and doesn't require processing overhead for the encryption

Are you referring to the client side of the connection or the server side? On the client slide, mobile devices have been able to decrypt in real time since at least the release of the original iPhone. If you're referring to a battery life hit, I imagine that a lot of users spend more megabytes browsing Facebook than downloading or updating applications, and Facebook already has to be encrypted in order not to leak the user's session cookie to users of Firesheep. And if your server's CPU can encrypt as fast as its network interface can shoot out packets, there's little noticeable overhead. TLS might be expensive when you're rapidly handshaking to create new connections, but there aren't quite as many new connections when bulk-encrypting APK file downloads sized in the multiple megabytes.

Re: So... (1)

AmiMoJo (196126) | about a year ago | (#44223813)

Caching.

Re: So... (0)

Bing Tsher E (943915) | about a year ago | (#44220885)

So the way to install a compromised app on someone's Android system is to lurk in the shadows with a complete set of compromised copies of everything in the Google PlayStore and sniffing in hopes of intercepting someone's traffic then quickly to insert a compromised copy of something midstream with a man-in-the-middle attack.

Doesn't sound like a very robust vector.

Hint: real-life hacking is all automated (5, Interesting)

cbhacking (979169) | about a year ago | (#44221053)

If by "lurk in the shadows" you mean "write a little Python script for a Raspberry Pi tucked behind a chair at your local Starbucks", and by "with a complete set of compromised copies of everything in the Google PlayStore" you mean "have the script be able to inject malicious code dynamically into an any APK in a few milliseconds", and by "sniffing in hopes of intercepting someone's traffic" you mean "running a persistent ARP spoofing attack that routes all external traffic across the network through said RaPi 24/7", and by "quickly to insert a compromised copy of something midstream with a man-in-the-middle attack" you mean "implement basic automated intercepting proxy functionality such as is common in dozens of existing tools"... then yes.

I don't think you realize how easy this kind of thing would be. Computers are tiny, silent, wireless, innocuous, and cheap these days. They are more than capable of modifying a typical APK in flight without introducing a human-noteworthy amount of latency. They can gain a MitM position easily an hold it for as long as the network stays up.

Yeah, those who stick to their cellular networks for app downloading are better off (unless there's a femtocell on that network and the attacker has access to it...) but for a few hours of hacking and less than $50 per location counting WiFi adaptor, you could catch a lot of people using WiFi on their phones.

Re:Hint: real-life hacking is all automated (1)

smash (1351) | about a year ago | (#44222401)

Exactly. People who aren't seeing this as being a major, major problem just aren't thinking maliciously enough.

Re:Hint: real-life hacking is all automated (1)

Bing Tsher E (943915) | about a year ago | (#44223829)

It still sounds like $50 per location to install something that gets 5-6 opportunities a week to inject malware. If the traffic being intercepted and corrupted was more common than APK files, it would maybe, possibly, be cost-effective to maintain this constellation of $50 Raspberry Pi systems in local Starbucks. As it is, people don't install new APKs that frequently, let alone install them in coffee bars.

It does sound like the big return would be in nabbing Raspberry Pi hardware you find hidden behind chairs. What are they selling for on eBay at present?

Re:Hint: real-life hacking is all automated (1)

AmiMoJo (196126) | about a year ago | (#44223885)

Google Play has already fixed this so you would have to target other sources of applications. When you download an APK Play itself verifies it even if the OS hasn't been patched, and everyone going back to at least Gingerbread (I think even Froyo and Doughnut too) gets updates to Play.

Re:Hint: real-life hacking is all automated (1)

ashpool7 (18172) | about a year ago | (#44233881)

Do Google Play downloads go over SSL? Does Google Play fail to work if the SSL verification fails against the installed CAs? Does that Raspberry Pi have its SSL cert installed on the phone?

It's not that easy...

(...or maybe it is, I'm assuming Google wasn't stupid when it comes to the first two questions.)

Re: So... (0)

Anonymous Coward | about a year ago | (#44221431)

so... connecting via ethernet I'm ok?

Re: So... (1)

smash (1351) | about a year ago | (#44222411)

Not really [wikipedia.org]

Re:So... (0)

Anonymous Coward | about a year ago | (#44221061)

malicious via an update to an existing app maybe.

Re:So... (0)

Anonymous Coward | about a year ago | (#44224455)

this still requires injecting the hostile patch into the Play Store via a trusted account or by convincing some sap to side load it.

I thought android users were recommend to exercise their "freedom" by sideloading apps as a big FU gesture towards the poor ios users restricted by their appstore walled garden. Its like recommending you use random needles found on the street for injections rather than licensed/sterilized ones. Sure you might get some "freedom" in that you can use some unlicensed medicines that might or might not work.. but occasionally also get AIDS.

Re:So... (1)

Andy Dodd (701) | about a year ago | (#44225187)

Also note that I believe Google is now scanning for APKs that have duplicate file entries - so this should (or will soon) get blocked right in the Play Store even with a trusted account, and also will likely get caught by Google's sideload malware scanning capabilities.

In short, this "master key" is of no impact to any user that applies the most basic levels of common sense (don't sideload shit from sources you don't trust.)

This Is The Problem With Smart Phones (1)

Anonymous Coward | about a year ago | (#44220731)

Their is a big difference between OS vendors' attitudes toward mobile devices and desktop/laptop computers. Many phones will never get - or even be able to run - the newer versions of Android that will have this flaw patched. Desktops & laptops get much longer support for their OS's.

Yes, I know some Apple computers can't run the latest and greatest anymore. That's due to a hardware architecture change that took place several years ago.

Re:This Is The Problem With Smart Phones (0)

Anonymous Coward | about a year ago | (#44220797)

Their is a big difference ...

D'oh! That should have been 'There'.

Re:This Is The Problem With Smart Phones (1)

Anonymous Coward | about a year ago | (#44221093)

Your an AC. Their not going to care.

Re:This Is The Problem With Smart Phones (1)

smash (1351) | about a year ago | (#44222421)

I see what you did they're.

Re:This Is The Problem With Smart Phones (2)

gnoshi (314933) | about a year ago | (#44220821)

The 'get' is very true, the 'be able to run' is less true.
If you look at some of the current 'budget' phones running 4.x, the specs are equivalent to previous phones which have ended with support for 2.2 or 2.3.
Also, many phones have quite functional CyanogenMod releases based on 4.x when the most recent official release is 2.2 (Motorola Defy for example) or 2.3. This reflects a problem of desire on the part of manufacturers. (Perhaps also a problem of a lack of legal obligation to provide at least security updates for a period of time, depending on your perspective).

Re:This Is The Problem With Smart Phones (0)

Anonymous Coward | about a year ago | (#44221721)

Yes, modding, rooting, etc the phone means it *can* run a later release. Just because there are some people who are technically capable of installing it via a manual process the masses can not and will not. What percent of the population is technically capable of performing this task? Less than 1%? Maybe 1%? That means almost every older phone out there will never have the patch that fixes this security vulnerability.

Re:This Is The Problem With Smart Phones (1)

adolf (21054) | about a year ago | (#44222571)

Yes, modding, rooting, etc the phone means it *can* run a later release. Just because there are some people who are technically capable of installing it via a manual process the masses can not and will not. What percent of the population is technically capable of performing this task? Less than 1%? Maybe 1%? That means almost every older phone out there will never have the patch that fixes this security vulnerability.

*shrug*

Back when I was a kid, people upgraded their own computers: From MS-DOS 3.3 to MS-DOS 5, from Windows 3.1 to Windows 95.

They usually even got it right. I'm pretty sure the Mac and Amiga usually got it right, too.

You think that just because it's an Android pocket computer, that people can't get it right? Hogwash. I have (albeit only slightly) more faith in folks than that.

Re:This Is The Problem With Smart Phones (1)

Krojack (575051) | about a year ago | (#44225127)

Installing ROMS is pretty easy. It's the initial rooting and installing the compatible recovery that could go wrong and brick the device. Some phones such as the Samsung Galaxy Skyrock is ungodly easy while others can cause sweat beads running down your face while doing it. I was scared shitless while rooting my HTC Thunderbolt. It was the first phone I ever rooted. When I bought my Note 2, I had it rooted within 15 minutes of getting home from Best Buy. It was rather easy thanks to Samsung's built in 'Downloader'.

In a phone utopia world, once a manufacture stop updating a device they should put out a patch that installs a recovery for you so you can then do whatever you want with your phone. The networks however (mainly Verizon) won't allow this.

Re:This Is The Problem With Smart Phones (1)

damium (615833) | about a year ago | (#44222669)

Indeed, also many of these fixes can also be/are already backported to older releases. The manufactures just don't care enough to build and test them and if they did the carriers don't want to send a patch through QA and the side deals for many branded phones don't let the manufactures publish updates directly.

A malicious APK? (5, Funny)

Anonymous Coward | about a year ago | (#44220735)

There's only one solution for a malicious APK.

We need a custom HOSTS file ...

Re:A malicious APK? (1)

snikulin (889460) | about a year ago | (#44220949)

nonono! We need to assign a governmental agency to watch all our traffic and block all malicious content.
 

IF you can ID where it's served up from? (0)

Anonymous Coward | about a year ago | (#44224061)

You're correct - a custom hosts file can block that out, no questions asked. "You can't get burned if you can't touch the flame" so-to-speak! Yes - You also can load even load up a custom hosts file on Android os bearing smartphones you know, using adb (Android Debugging Bridge) & its "pull" command - easily.

I'd recommend using a smaller 'optimized' hosts file and yes producers of them DO put those out!

("Optmized" meaning carrying more current infestors vs. older ones that might be using "FastFlux" or Dynamic DNS faults, since they're larger & space on Android's not exactly 'bountiful' imo, but less line entry records overall from over time).

* You end up with the same list of benefits I enumerate in the link below (where my custom hosts file import/normalize-depuplicate/sort/create program is) - & I do, as-per-my-usual, challenge ANY "naysayers" to disprove my points on custom hosts files' value to end users in better added speed, security, reliability, & yes, even anonymity to an extent as well Nobody can, or ever does - it is, clearly impossible: It's not my fault these naysayer trolls, usually by ac posts, are easy to outthink! It's too easy to do, every single time for me. Their trollish reactions though? They're even funnier - "just when trolls thought they 'know it all', along comes me to school them", lol!

APK

P.S.=> However, since you're modded "funny"? Then, I can be a lot funnier & challenge you to disprove the enumerated list of points regarding the good benefits custom hosts files give end users of them in added speed, security, reliability, & even anonymity(to an extent vs. dns request logs + dnsbl's) in the link below :

http://start64.com/index.php?option=com_content&view=article&id=5851:apk-hosts-file-engine-64bit-version&catid=26:64bit-security-software&Itemid=74 [start64.com]

... apk

Speaking of "funny"... apk (0)

Anonymous Coward | about a year ago | (#44224315)

My "latest schooling" of Ash-Fox on DNS servers vs. Hosts files (which the latter gets you past the former's security shortcomings) -> http://news.slashdot.org/comments.pl?sid=3929071&cid=44223687 [slashdot.org]

* :)

That serves as a "prime example" of what I meant by "naysayer trolls" - especially when that dolt came in saying "I got the better of you APK" essentially - so much for that!

Well, that link above shows the truth of that, & it wasn't he who ended up on top... I did!

(On several grounds (including more power consumption, resources usages of all types, & more (like DNS faults listed there that yes, custom hosts files overcome, easily!))).

So, thus - As usual, I've just GOTTA say it, as-is-per-my-inimitable style: This? This was just "too, Too, TOO EASY - just '2ez'" & always is, vs. those coming in saying they 'schooled me' & I just re-annihilate them as I did in the link above!)

APK

P.S.=> Funnier still? I submitted a story on AdBlock everyone online is putting up (Especially since AdBlock doesn't do a 10th of what custom hosts files can adding more speed, security, reliability, & even anonymity to an extent for users of them) to this site yesterday - guess what?

It got REJECTED (gosh, doing an "NSA 'damage control'" suppression of information or what, morons? Too obvious!):

http://slashdot.org/submission/2783319/adblock-getting-paid-by-google-to-allow-their-ads [slashdot.org]

Not only was it rejected, but it was REMOVED from the submissions page even though it's valid...

Please - lmao: Can you "Open SORES" idiots be any more transparently STUPID or what? Your 'suggestion' to use AdBlock here, nigh constant, FAILS vs. my points (and, you all know it - especially since the makers of AdBlock "souled-out" they way they have)

... apk

Re:IF you can ID where it's served up from? (0)

Anonymous Coward | about a year ago | (#44225633)

Whoever you are, I hope you are OK.

Thanks (assuming you're not being sarcastic): (0)

Anonymous Coward | about a year ago | (#44230939)

I am, & better than most online, because of this http://start64.com/index.php?option=com_content&view=article&id=5851:apk-hosts-file-engine-64bit-version&catid=26:64bit-security-software&Itemid=74 [start64.com]

* Take a read there, especially the enumerated list of benefits you get in added speed, security, reliability, & even anonymity to an extent - you'll know WHY I said what I just did in response to you.

APK

P.S.=> HOWEVER: If you're just being a sarcastic trolls with some trite little phrase (meme b.s., comes & goes like the wind)? Then, as the Chinese say, iirc, to you in reply?? "May you live in interesting times" & as the southeners in the U.S. like to put it "Bless your heart!"... apk

Looks like AC had it already (1)

gnoshi (314933) | about a year ago | (#44220749)

From a previous AC comment [slashdot.org] :

APK's are signed with what amounts to the normal jar signing process. So either they have found a way to create a hash collision, or there's some other bug in the verification process that allows some unsigned code to be included in the file and executed.

Either way, you will still need to trick people into installing your version of the apk.

My guess is this: android just checks the first files matching in the jar/zip for the names, but installs the files found last in the jar(or vice versa, zip files can have multiples of the same filename).

Re:Looks like AC had it already (0)

Anonymous Coward | about a year ago | (#44220795)

Java, it keeps on giving.

But for real, it can't be that simple to exploit ?

Re:Looks like AC had it already (1)

johanwanderer (1078391) | about a year ago | (#44220823)

The people on xda-developers have been doing that for ages. That's how they mod the official APKs and change images to match the various themes.

Re:Looks like AC had it already (0)

Anonymous Coward | about a year ago | (#44221241)

You are kidding, right?

Re:Looks like AC had it already (1)

Picass0 (147474) | about a year ago | (#44221487)

When they mod a package it no longer matches the APK signature. On many Android phones if you install a custom (unsigned) kernel you will get a yellow triangle during boot.

I still don't get it... (1)

Anonymous Coward | about a year ago | (#44220759)

http://threatpost.com/android-vulnerability-enables-malicious-updates-to-bypass-digital-signatures/

“Users need to be cognizant of the source of applications they’re installing and trustworthiness of the source of APKs if they’re not installing from Google Play,” Forristal said. “If you don’t know where the APK came from, it’s no different than grabbing .exes from the Net. Make sure you’re not using apps from untrusted sources and stick to Google Play; Google mentioned it has inoculated Google Play looking for applications using this bug and those should not appear in Google Play.”

So, if a dev signs his app, as a way of guarantee that nothing from his compiler to user's phone tangled with it...
What is to say nobody on Google's side wont modify it?

Why would it being on AppStore be any more credible (in light of everything) than just a dev publishing it somewhere together with the digital fingerprint on his website?

What am I missing?

Summary of the exploit (4, Informative)

complete loony (663508) | about a year ago | (#44220901)

Add your exploit code to an existing apk without removing the original items, creating a zip file with duplicate entries. The original files match the signature, the duplicates are executed after installing.

Re:Summary of the exploit (2)

complete loony (663508) | about a year ago | (#44220951)

Looks like the fix they have applied will cause java.lang.zip.ZipFile to throw a ZipException, indicating a format error, whenever it encounters a duplicate entry in *any* zip file, for *any* application using android's dalvik JVM.

I'm not certain that's the correct response to this issue. Should a zip file with duplicate entries always be considered invalid?

Re:Summary of the exploit (0)

Anonymous Coward | about a year ago | (#44221045)

might as well. dupes are pointless.

Re:Summary of the exploit (1)

phantomfive (622387) | about a year ago | (#44221475)

What would that exactly mean, to have duplicate entries in a zip file? How would you even unzip it? You would end up having two files with the exact same name in a directory, an impossibility in most filesystems.

I imagine that's how the exploit worked, when they checked the signatures, they just unzipped the first file that matched the signature name (which would be the original file), then they unzipped it, the first file being unzipped first, then the second file being unzipped and replacing the first.

Re:Summary of the exploit (1)

gl4ss (559668) | about a year ago | (#44222875)

What would that exactly mean, to have duplicate entries in a zip file? How would you even unzip it? You would end up having two files with the exact same name in a directory, an impossibility in most filesystems.
  I imagine that's how the exploit worked, when they checked the signatures, they just unzipped the first file that matched the signature name (which would be the original file), then they unzipped it, the first file being unzipped first, then the second file being unzipped and replacing the first.

you can just pick which files you unzip out of the zip. there's no problem in the format itself, there's no rule saying that you would have to unzip them all at once. this is the thought hole the google developers fell into. I don't understand why they don't sign the zip file itself and add the signature as a block at the end of fixed length(the way .jar signing for j2me worked was that you had to have the .jad application descriptor file distributed at the same time, that complicated things a lot in regards of distribution).

Re:Summary of the exploit (0)

phantomfive (622387) | about a year ago | (#44225441)

Well, no one ever accused the Android team of thoughtful, quality programming.

Re:Summary of the exploit (2)

yincrash (854885) | about a year ago | (#44221223)

Does this affect anything jars that are signed with the standard java jar signer as well?

Re:Summary of the exploit (1)

phantomfive (622387) | about a year ago | (#44221477)

I don't think it was a problem at the signing stage, it was a vulnerability at the stage where they check the signature.

Re:Summary of the exploit (1)

rabtech (223758) | about a year ago | (#44221693)

So basically the signature only verifies the first instance of a file it finds in the archive, but when extracted it extracts the latest. In fact ZIP (and RAR IIRC) allow overwriting a file with a newer version later in the archive; probably a hold-over from the floppy-swapping and/or tape days when you needed such abilities.

Reminds me of the chimera file exploits that use the fact that many common file formats like ZIP and PDF will ignore extraneous data, scan into the file looking for a header, etc to make one file appear to be a valid file of many types. Often, virus scanners fail to notice this and will scan eg the PDF while ignoring the ZIP payload, but unzip utilities just scan forward until they find the ZIP header.

The real fail here will be the fact that at least half (if not 80-90%) of all Android devices won't have a patch released *period*, never mind people bothering to install the patch.

Re:Summary of the exploit (0)

Anonymous Coward | about a year ago | (#44222847)

haa! I guessed it right the first time!

f*cking stupid googleheads.

swearwords insert a delay into slashdot commenting.

Re:Summary of the exploit (1)

selectspec (74651) | about a year ago | (#44223475)

That is unbelievable that they would overlook that. Thanks for the explanation.

That's ...helpful... (1)

Anonymous Coward | about a year ago | (#44221031)

to people who want to use the exploit to compromise your phone. It's not helpful to Android users or to legitimate developers.

How does that help me? (2)

Shavano (2541114) | about a year ago | (#44221091)

Google said that a patch for Forristal's vulnerability was provided to Google's OEM and carrier partners in March, and that some (Samsung) have already shipping a patched version of Android to customers. However, that response hasn't been universal — a reflection of Android's fragmented install base."

It's nice that Google's OEM and carrier parters are getting a patch but what's their mechanism for distributing the patch to the installed base of Donut, Eclair, Froyo, Gingerbread, Ice Cream Sandwich and Jelly Bean users in the field who would like their phones to not be infected with malware? And does it affect Kindles and other systems running on Android forks?

Google Play Services (2)

tepples (727027) | about a year ago | (#44221489)

One method is Google Play Services. I've noticed that even on a 2.2 device, the app formerly known as Android Market installed a new application called "Google Settings" and an .apk file handler called "Verify and Install". Apparently app verification, introduced alongside Android 4.2 [thenextweb.com] , is some subset of the "bouncer" that Google uses to reject applications exhibiting the most common malicious behaviors, and Google could easily update it to reject .apk files that include two files with the same name.

Re:How does that help me? (1)

gl4ss (559668) | about a year ago | (#44222849)

a lot of the attack would be mitigated by simply having the apk downloads from the market be https.. they don't need to update android itself for that, just the play store client.

Android security updates? (1)

Compaqt (1758360) | about a year ago | (#44221137)

It seems that most Android manufacturers don't upgrade major versions for their phones (2.3 to 4.x).

That may make sense because the newer versions may relate to features or power the older phones don't have.

But do the manufs/Google at least offer minor upgrades (2.3.x) for security/backport purposes?

It seems that Google offering a patch which would only go into new Samsung phones is about useless.

Re:Android security updates? (1)

Nemyst (1383049) | about a year ago | (#44222003)

Google's distributed it to the manufacturers, Samsung was the first to implement and push it. Doesn't mean they're the only ones with the ability to do it, only that they're the only ones to have done it thus far. I'd also expect this fix to be in the stock Android distributions.

Old devices running on 2.3 will never see updates as they're already considered long out of support. 2.3.x devices might see something due to GB still being widely used by cheaper and older devices. 3.x devices are dead and buried. 4.x devices will almost certainly see the update in one form or another, though this may be dependent on (usually terrible) manufacturer support.

Re:Android security updates? (1)

Skapare (16644) | about a year ago | (#44222345)

Buy a new phone. You know they want you to.

Re:Android security updates? (1)

gl4ss (559668) | about a year ago | (#44222853)

they could just distribute the patch through a new google play store client.

anyhow, the way the attack works is laughable, like they had a perfectly brilliant idiot design the system(who didn't know shit about how zip works). bad, bad google.

My take on this as an Android developer (0)

Anonymous Coward | about a year ago | (#44222763)

If you're thinking about how this could be exploited by tricking people into downloading a malicious app, you're thinking about it the wrong way. The greatest danger of this exploit is that it could be used to access the "private" data of any device you have access to. Android will not allow you to install a new version of an app over adb (think USB console) unless the signatures match. To install a malicious version of an app, you'd normally have to uninstall the old version, deleting its data with it. But using this exploit, you could install a version of the app that would reveal the data. So now a stolen phone is not just a stolen phone; its potentially a stolen identity.

Re:My take on this as an Android developer (1)

gl4ss (559668) | about a year ago | (#44222861)

If you're thinking about how this could be exploited by tricking people into downloading a malicious app, you're thinking about it the wrong way. The greatest danger of this exploit is that it could be used to access the "private" data of any device you have access to. Android will not allow you to install a new version of an app over adb (think USB console) unless the signatures match. To install a malicious version of an app, you'd normally have to uninstall the old version, deleting its data with it. But using this exploit, you could install a version of the app that would reveal the data. So now a stolen phone is not just a stolen phone; its potentially a stolen identity.

not really. you could mitm the apk downloads from play store(it's plain http).

Re:My take on this as an Android developer (1)

Max Threshold (540114) | about a year ago | (#44235751)

Easily remedied. The other thing, not so much.

Come to think of it, this would allow security researchers (of any hat color) to audit the "private" data stored by any app. Having seen how some supposedly "secure" apps handle their data, this could be illuminating. My guess is that Apple's shareholders would love to see such a survey.

App stores == terrorism?? Work with me here... (1)

fzammett (255288) | about a year ago | (#44227611)

It's kind of interesting to me how what we've seen with the rise of the app store model has largely mirrored what we've seen in the "real world" post-9/11. It hasn't quite been simultaneous, but pretty close.

What I mean is that a lot of people love the app store model and always say how it's "safer". Especially when talking about Apple, you have a gatekeeper checking on the safety of apps, to at least some degree. They ensure what gets through won't hurt you (in theory... but, to be fair, they do pretty well in practice too).

However, there's a cost: at least some decrease in "freedom". Not just anyone can throw an app out to the world of iOS users. If Apple doesn't like your app for any reason, you don't get to distribute to (most) iOS users. Sure, there's jailbreaking and Cydia and all of that, but let's be honest: that's a pretty small percentage of more technically-oriented users. For *most* iOS users, your app doesn't exist if Apple doesn't want it to.

The Android model is the opposite or course: there is virtually no barrier to entry. It's very easy to get into the Play store whether your app is "safe" or not. Oh, they're doing some checks now, but at the end of the day I think even us Android fans acknowledge that it's still more or less a wild west environment. And that says nothing of side-loading either: if you don't get in the store, or don't want to, no big deal, you can still distribute directly to users. Flipping a setting in options isn't the same as jailbreaking so you aren't limited to just "technical" users.

Post-9/11, people seem to be willing to give up some degree of freedom for safety (whether that safety is just perceived or not is a whole other discussion). No, not everyone of course, and yes, there's limits to what people will accept. But, aren't we seeing those bounds pushed more and more every day? Hasn't Snowden showed us that a large chunk of the American population is more than happy to give up privacy to at least *feel* safer?

It's no different in the app world. Lots of people swear by the closed, "walled garden" approach of Apple. They claim it's safer and the quality is better. Well, the former is fairly easy to show, the later is highly subjective, but what's obvious in either case is that there's a decrease in freedom. You may see the tradeoff as worth it. That's your call. People love Apple whether I do or not and I'm not going to try and convince them they're wrong. There's pluses and minuses to both approaches. But at the end of the day, Apple is, at least in part, deciding what you can and can't install on you device.

It's just interesting to me how people in both situations seem so willing to say "eh, make me safer, or at least make me THINK I'm safer, and you can have some measure of control over what I do". How that's acceptable to ANY American in either case is beyond me frankly and I think it shows that our societal values have eroded tremendously. Sure, yes, Apple controlling what apps I can install on my phone is VASTLY different from the TSA patting me down to ensure I don't bring a bomb on a plane. I dare say nobody's life is at stake because Apple decides I used the word cock one too many times in my app. But the fundamental concept is the same: safety in exchange for freedom.

But, underneath both is the same warped thinking: someone else is better suited to keeping you safe than YOU are. It's someone else' responsibility to keep you safe. Someone else can make decisions for you because you are unable or unwilling to do so. Yes, I'm saying you're opinion on the walled garden app store model vs. the Android "wild west" approach informs your take on society at large and what you are willing to let any government do to you. If you're in the Apple camp then you're probably perfectly willing to let the government trample your liberties in exchange for possibly less chance of being killed. The mentality of both is the same. If, on the other hand, you're willing to be responsible for yourself and control your own destiny, the Android approach is probably better-suited to you.

(of course, we'll have a similar discussion about how Google is a data whore above all others and what THAT means, but that's for another day)

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>