CopperheadOS: Securing the Android

Where to start?

When building an Android-based system, one of the first questions to answer is: which system should one start with? When the alpha release was announced, CopperheadOS was based on the CyanogenMod 12.1 branch. As of the beta, however, things have changed; CopperheadOS is now based directly on the Android Open Source Project (AOSP) release. That is a significant change, but the developers are clear on their reasons for making it:

One unfortunate effect of this change for some users is that the number of supported devices has dropped; the beta is only available for Nexus 5, 5X, and 9 devices, with Nexus 6/6P planned for "some point down the road". Expanding the hardware range further is likely to be challenging given amount of proprietary software required to make each new platform work. The CopperheadOS developers do not say so anywhere, but it seems likely that they are hoping to be able to work with handset vendors in the future, once they have a viable distribution to offer.

PaX and Zygote

CopperheadOS starts with AOSP, but makes a number of changes aimed at improving the security of the system; one of the first of those is to apply the PaX security patches. One of the key benefits that comes from PaX is strengthening Android's resistance to executing code that happens to find its way into writable memory. Android makes extensive use of just-in-time compilation, making this task harder, but the CopperheadOS developers were still able to make some progress; see this page for details on what they have done.

Another area of work is address-space layout randomization (ASLR). Android already makes heavy use of ASLR; indeed, recent patches aimed at increasing ASLR entropy came from Google. But there is an interesting and potentially fatal flaw in the form of Android's "Zygote" mechanism. Starting up a Java executable can require loading a lot of class modules, which takes time; replicating that loaded code across each process can also consume a lot of memory. Zygote addresses these problems by having a single process that loads all of the class libraries. When it is time to launch a new app, the Zygote process forks, then begins running the app code directly (without an exec() call).

This model is certainly efficient, in that new apps can launch quickly and they will have all the needed classes already loaded and ready to go; those classes also need only be stored in memory once. The problem with taking away the exec() stage, though, is that it defeats ASLR; every app running on a given system will have the same randomization offsets. An attacker who is able to run an app on a targeted system, or who can extract the layout information from a running app, will know the layouts used for all running apps, present and future.

The solution used in CopperheadOS is to restore the exec() call to the Zygote app-launch mechanism. That slows down the launch noticeably, but the result is still said to be "fast enough for the niche". There is also an increase in memory use, though that isn't necessarily a huge problem on contemporary devices. In the future, CopperheadOS may adopt the "Morula" approach described in this paper [PDF]; it works, once again, by creating each app process with exec(), but it aims to reduce the startup latency by creating and initializing new processes in the background before apps are launched. When the time comes to launch a new app, one of the existing processes reads and runs the code much like the existing Zygote system, but it is running with its own set of ASLR offsets.

Other enhancements

There has been some work done to harden the Bionic C library used by Android. That includes instrumenting a number of functions (mostly system call wrappers) with the _FORTIFY_SOURCE option to prevent buffer overflows. Happily, much of this work has been submitted to and accepted by AOSP, so it will eventually appear in regular Android releases as well. The malloc() implementation has been torn out and replaced with the OpenBSD version, which features better layout randomization. This allocator also overwrites data when chunks of memory are freed. Guard pages and additional randomization have been applied to stacks; this work, too, has been sent upstream.

One of the claimed features is MAC-address randomization, making it difficult to track a device from one access-point connection to the next. As of this writing, though, that feature has been disabled after showing an unpleasant tendency toward breaking WiFi connections altogether.

Another significant change is to separate the password used to encrypt storage from the one used to unlock the device. That allows the unlocking password to be relatively simple, while the encryption password can be obnoxious and difficult to guess. After five failed attempts to unlock the device, a reboot will be forced, causing any attacker to be confronted with the (presumably stronger) encryption password.

CopperheadOS, like CyanogenMod, comes without Google Play Services and the associated apps. Instead, it has F-Droid installed — a solution that will be sufficient for some users, but not for others. Those needing the Google apps can download a separate bundle and install them much like CyanogenMod users do. It's worth noting (as was done in this tracker issue) that even a system without the Google apps will make occasional connections to Google servers; there are currently no plans to change that behavior.

Giving it a try

Installation of CopperheadOS onto a Nexus 5 handset is a relatively straightforward affair. The bootloader must be unlocked, of course, if that has not been done so far; that leads to that moment where one has to be absolutely sure of having backed up everything of interest on the device. The actual installation appears to have reused the mechanism provided with the stock Android images; one needs only plug in a phone running in the bootloader and fire off the provided flash_all.sh script. A few minutes later, the phone boots into CopperheadOS.

Anybody looking for something shiny and new is going to be disappointed, though; the nature of this distribution is to make changes that are not really visible. The one thing that does stand out — the lack of Google apps — is not hugely impressive. Those apps can be installed (using the packages that circulate for CyanogenMod installations), but the user is left to figure that out on their own; it is clearly not a priority for the CopperheadOS developers. Of course, if one is installing a hardened distribution like this, it is worth asking whether installing the whole Google apps ecosystem is in line with one's security requirements.

The distribution functions like an ordinary system for the most part. The startup latency caused by the Zygote changes were difficult to notice; those changes seem like a good tradeoff on a device like this. One non-repeatable app crash was observed while playing with the system — something that is far from unheard-of on regular Android. CopperheadOS seems to be a working Android build; whether it truly meets its security goals is, naturally, a bit harder to judge.

Keeping current

A secure device operating system will not stay that way without regular updates. CopperheadOS includes an over-the-air update mechanism with, as evidenced by the downloads page, frequent updates going out. Being based on AOSP should allow CopperheadOS to use the updates now produced regularly for Android, but the project appears to be creating its own updates more frequently than that. Updates are signed, so it should not be possible for a random attacker to push a malicious update into a system.

On the surface, CopperheadOS appears to have done a lot of things right. It offers a distribution that looks a lot like pristine AOSP, but with a lot more security built-in. The developers appear to have taken an upstream-friendly approach to their work, pushing at least some of it back into AOSP. The Android developers are already concerned about security, but there is certainly room for a variant catering to users who want an even sharper focus in that area.

If there are concerns to be raised, they are around sustainability. Developing this distribution and supporting it with updates requires a fair amount of time and resources. It seems clear that the CopperheadOS developers would like for this project to fund their work; their web site talks about selling phones with CopperheadOS installed, for example. If they succeed, then this distribution should have a bright economic future and, hopefully, a bright community-oriented future as well. Otherwise the whole thing is likely to fade away, with users perhaps not noticing until it occurs to them to wonder why they haven't seen an update for a while. But that is a risk inherent to most projects, and to many commercial products as well. For now, it is good to see this kind of work being done.