By Jake Edge
July 10, 2013
A 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.
Comments (6 posted)
Brief items
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.
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.
—
Adam Caudill is ... unimpressed ... with Cryptocat
Destroying cameras? And mice? Over malware? Are you serious?
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.
—
Mario
Aguilar is ... unimpressed ... by a US government malware prevention scheme
Comments (none posted)
New vulnerabilities
glpi: three largely unspecified vulnerabilities
Comments (none posted)
kernel: multiple vulnerabilities
| Package(s): | kernel |
CVE #(s): | CVE-2013-1059
CVE-2013-2234
|
| Created: | July 8, 2013 |
Updated: | August 20, 2013 |
| Description: |
From the Red Hat bugzilla [1, 2]:
Linux kernel built with the IPSec key_socket support(CONFIG_NET_KEY=m) is
vulnerable to an information leakage flaw. It occurs while using key_socket's
notify interface.
A user/program able to access the PF_KEY key_sockets could use this flaw to
leak kernel memory bytes. (CVE-2013-2234)
Linux kernel built with the Ceph core library(CONFIG_CEPH_LIB) support is
vulnerable to a NULL pointer dereference flaw. It could occur while handling
auth_reply messages from a CEPH client.
A remote user/program could use this flaw to crash the system, resulting in
denial of service. (CVE-2013-1059) |
| Alerts: |
|
Comments (none posted)
kernel: multiple vulnerabilities
| Package(s): | kernel |
CVE #(s): | CVE-2013-2232
CVE-2013-2237
|
| Created: | July 8, 2013 |
Updated: | July 18, 2013 |
| Description: |
From the CVE entries:
The ip6_sk_dst_check function in net/ipv6/ip6_output.c in the Linux kernel before 3.10 allows local users to cause a denial of service (system crash) by using an AF_INET6 socket for a connection to an IPv4 interface. (CVE-2013-2232)
The key_notify_policy_flush function in net/key/af_key.c in the Linux kernel before 3.9 does not initialize a certain structure member, which allows local users to obtain sensitive information from kernel heap memory by reading a broadcast message from the notify_policy interface of an IPSec key_socket.
(CVE-2013-2237) |
| Alerts: |
|
Comments (none posted)
kernel: denial of service
| Package(s): | kernel |
CVE #(s): | |
| Created: | July 8, 2013 |
Updated: | July 10, 2013 |
| Description: |
From the SUSE advisory:
The SUSE Linux Enterprise 11 Service Pack 2 kernel was
respun with the 3.0.80 update to fix a severe
compatibility problem with kernel module packages (KMPs)
like e.g. drbd.
An incompatible ABI change could lead to those modules not
correctly working or crashing on loading and is fixed by
this update. |
| Alerts: |
|
Comments (none posted)
nagios: information disclosure
| Package(s): | nagios |
CVE #(s): | CVE-2013-2214
|
| Created: | July 8, 2013 |
Updated: | July 10, 2013 |
| Description: |
From the SUSE bugzilla entry:
It was reported that Nagios 3.4.4 at least, and possibly earlier
versions, would allow users with access to Nagios to obtain full access
to the servicegroup overview, even if they are not authorized to view
all of the systems (not configured for this ability in the
authorized_for_* configuration option). This includes the servicegroup
overview, summary, and grid.
Provided the user has access to view some services, they will be able to
see all services (including those they should not see). Note that the
user in question must have access to some services and must have access
to Nagios to begin with. |
| Alerts: |
|
Comments (none posted)
python-bugzilla: missing certificate verification
| Package(s): | python-bugzilla |
CVE #(s): | CVE-2013-2191
|
| Created: | July 8, 2013 |
Updated: | July 10, 2013 |
| Description: |
From the SUSE bugzilla entry:
It was found that python-bugzilla, a Python library for interacting with
Bugzilla instances over XML-RPC functionality, did not perform X.509
certificate verification when using secured SSL connection. A man-in-the-middle
(MiTM) attacker could use this flaw to spoof Bugzilla server via an arbitrary
certificate. |
| Alerts: |
|
Comments (none posted)
ReviewBoard: cross-site scripting
| Package(s): | ReviewBoard |
CVE #(s): | CVE-2013-2209
|
| Created: | July 8, 2013 |
Updated: | July 10, 2013 |
| Description: |
From the Red Hat bugzilla:
A persistent / stored cross-site scripting (XSS) flaw was found in the way reviews dropdown of Review Board, a web-based code review tool, performed sanitization of certain user information (full name). A remote attacker could provide a specially-crafted URL that, when visited would lead to arbitrary HTML or web script execution in the context of Review Board user's session.
See the Review Board announcement for additional information. |
| Alerts: |
|
Comments (none posted)
ssmtp: world-readable password file
| Package(s): | ssmtp |
CVE #(s): | |
| Created: | July 4, 2013 |
Updated: | July 10, 2013 |
| Description: |
From the Red Hat bugzilla entry:
In order to have ssmtp working for every user on the machine, the file /etc/ssmtp/ssmtp.conf must be readable by every user (others must at least have the read right to this file).
If an authentication smtp server is used (as gmail for example), the login and password appears in clear text in ssmtp.conf. This is obviously a security problem. |
| Alerts: |
|
Comments (none posted)
xorg-x11-server: denial of service
| Package(s): | xorg-x11-server |
CVE #(s): | |
| Created: | July 5, 2013 |
Updated: | July 10, 2013 |
| Description: |
From the openSUSE bug report:
If a client sends a request larger than maxBigRequestSize, the server is
supposed to ignore it.
Before commit cf88363d, the server would simply disconnect the client. After
that commit, it attempts to gracefully ignore the request by remembering how
long the client specified the request to be, and ignoring that many bytes.
However, if a client sends a BigReq header with a large size and disconnects
before actually sending the rest of the specified request, the server will
reuse the ConnectionInput buffer without resetting the ignoreBytes field. This
makes the server ignore new X clients' requests. |
| Alerts: |
|
Comments (none posted)
Page editor: Jake Edge
Next page: Kernel development>>
