LWN Weekly Edition
Front pageSecurity
Kernel development
Distributions
Development
Announcements
->One big page
This page
Previous weekFollowing week
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
SecuritySubverting Android package verificationA bug in Android that Google has known about since February is finally coming to light. It affects the integrity of Android packages, allowing an attacker to create a malicious version of an app that still passes the cryptographic signature check. While it doesn't affect any packages in Google's Play store, it certainly could have affected packages that came from elsewhere—"sideloaded" apps. In fact, since the flaw goes back to Android 1.6 ("Donut") and hasn't been fixed for the vast majority of Android firmware versions, it still affects hundreds of millions of devices. The actual bug is fairly trivial; a four-line patch is enough to fix it. The problem stems from the fact that the Android ZIP file decoder will allow archives to contain more than one file with the same name. That might not be a big deal, except that there is an inconsistency on which of the two identically named files in the archive is used. It turns out that the Android package verification code uses the last file in the archive, while the app uses the first. That situation means that an attacker can take an existing, cryptographically signed .apk file (in Android's application package file format—essentially just a ZIP file with defined contents) and massage it into one that will run malicious code, while still passing the signature checks. By placing a malicious file with the same name as a signed file in the archive before the existing files, an attacker gets their fondest wish: an app that passes the security checks but compromises the device. From a device's perspective, the compromised package looks for all the world like a valid app signed by the app vendor—but it isn't. It contains code that comes from elsewhere but will be run by the device when the app is loaded. So the user gets an app that is rather different than what they expect based on the signature. Bouncing Cows has now become a bouncing Trojan horse. The problem was discovered by Bluebox Security and reported to Google in February. It was first "announced" in a tweet in March that just referred to the Android bug number (8219321). More information about the flaw came in an early July blog post by Bluebox CTO Jeff Forristal. He called it a "master key" vulnerability, which may have been meant to misdirect others from discovering the flaw. But he also evidently wanted to increase the anticipation for his Black Hat USA talk in August. It would seem that there was enough information in that post and elsewhere for the CyanogenMod team to figure out the problem. A patch landed in the CyanogenMod tree on July 7 that disabled the multiple filename "feature". A bit more information appears in the CYAN-1602 bug report. Interestingly, the patch comes from Google and was committed into some internal Google tree on February 18. That may suggest the existence of a back channel between Google and CyanogenMod, which would be a good—if, perhaps, surprising—development. It doesn't require a very sophisticated program to perform the attack, and a simple proof of concept was posted on July 8. It uses Python's ZIP file library, as most ZIP tools will not allow duplicate file names. A more sophisticated, Java-based tool is also available. The biggest danger is from sideloaded system apps, which have more privileges than regular Android apps. System apps can effectively take over the phone completely to use any of its services or devices as well as to access any installed app and its data. Depending on the phone, however, the system apps may be stored in a read-only part of the system, so it would require a full Android update to change. But there is plenty of damage that a regular app can do, depending on the permissions required when it was installed. Attackers would seem likely to choose to compromise apps with numerous permissions when (ab)using this vulnerability. In some sense, though, the vulnerability doesn't give the apps any more privileges than they already have. A malicious app (either system or regular) could already perform any of the actions that a compromised app could perform. The difference is that apps in the Play store, or those installed by phone vendors, are not expected to join botnets, send contact information to remote sites, activate the microphone or GPS without user approval, or any other "tricks" that an attacker might want to do. By giving permission to apps (either explicitly when installing them or implicitly by buying a phone with system apps installed), the user is allowing various types of activities. Apps that violate the expectations will presumably find themselves blocked or removed from the Play store, while misbehaving system apps will, at least, negatively impact the phone vendor or carrier's reputation. Sideloading apps, especially system apps, comes with some inherent risk that may largely not be present when getting them through "normal" channels. In an interview at the CIO web site, Forristal said that Google blocks Play store apps with duplicate filenames, and Google indicated that none had been found when that blocking began. So the problem exists only for those users who sideload apps from other sites. That may be a minority of Android users, but it still seems like the kind of bug that should have been fixed long ago. As the CyanogenMod patch indicates, however, Google did fix this in its trees shortly after the report. So far, though, only the Galaxy S4 has been reported to have been updated. The Android Open Source Project (AOSP) code has not been updated with a fix, yet, either. It's a little puzzling why a trivial fix, seemingly with few, if any, downsides, has not seen more proliferation through the Android ecosystem. In light of Google's disclosure policy, it would seem that the company should have been more forthcoming about this bug. Given that Bluebox is trying to make a splash with the vulnerability at Black Hat, perhaps there was a request—or requirement—to withhold the details, or even existence, of the flaw until after the presentation. If so, it is a sad statement about the state of security vulnerability research and disclosure today. Cryptographic signing is specifically targeted at preventing precisely this kind of attack, of course. This vulnerability serves as a reminder that it isn't just the cryptographic code that needs vetting, but that all of the steps in the signing and packaging process are important pieces of the puzzle too. In this case, an obscure bug in decoding a decades-old format led to a complete circumvention of the security meant to be provided by the signatures—it makes one wonder what other weird little corner cases lurk out there waiting to be discovered, or exploited.
Brief items Security quotes of the week
The idea that copyright owners might convince a judge, or, worse, a jury
that because they found a copy of an e-book on the Pirate Bay originally
sold to me they can then hold me responsible or civilly liable is almost
certainly wrong, as a matter of law. At the very least, it’s a long shot
and a stupid legal bet. After all, it’s not illegal to lose your
computer. It’s not illegal to have it stolen or hacked. It’s not illegal to
throw away your computer or your hard drive. In many places, it’s not
illegal to give away your e-books, or to loan them. In some places, it’s
not illegal to sell your e-books.
— Cory
Doctorow on yet another e-book DRM scheme
Based on recent disclosures, we know that the NSA has decided to store encrypted communication for later analysis, and I think it’s safe to say that other countries follow suit. So it’s likely there are stored Cryptocat communications floating around in various spy agency archives. These agencies may have already found this issue and used it to view messages, or now that it’s public - they can do so easily.
— Adam Caudill is ... unimpressed ... with Cryptocat
This is where an issue like this can be so devastating, if those encrypted messages have been saved anywhere - any users engaged in activity that their local government doesn’t care for are now at risk. Personally, I wouldn’t trust Cryptocat until it’s had a true code audit (the pen-test they had last year clearly doesn’t count), and the crypto systems reviewed by a true cryptographer. If a mistake like this was allowed in, and overlooked for so long, I’ve no doubt that other weaknesses exist.
Destroying cameras? And mice? Over malware? Are you serious?
— Mario
Aguilar is ... unimpressed ... by a US government malware prevention scheme
Worse, the EDA [Economic Development Administration] continued destroying components until it could no longer afford to destroy them. In fact, the agency intended to continue destroying gear just as soon as it got more funds approved to do so. Uhh... okay! And no, it does not end there. It turns out the malware infection was absolutely routine. All the EDA had to do was isolate the affected components, remove the malware, reconnect the hardware and move on. NOAA, which received a notice at the same time as EDA, completed this operation in one month.
New vulnerabilities glpi: three largely unspecified vulnerabilities
kernel: multiple vulnerabilities
kernel: multiple vulnerabilities
kernel: denial of service
nagios: information disclosure
python-bugzilla: missing certificate verification
ReviewBoard: cross-site scripting
ssmtp: world-readable password file
xorg-x11-server: denial of service
Page editor: Jake Edge |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||