Copperhead CTO: Nexus Phones Already More Secure Than BlackBerry Priv

Copperhead is a Toronto-based security firm created this year that aims to significantly improve the security of Android by adding enhancements to Android's kernel and userspace that may not even be on Google's roadmap right now. The team, consisting of information security researchers, forensic analysts, and software developers, already open sourced an alpha-version of its own security-hardened CopperheadOS this summer. It has also been contributing security fixes and improvements to the Android Open Source Project (AOSP).

Soon after BlackBerry officially announced the Priv at the end of last week, Copperhead took issue with the fact that the Priv is already considered by many to be the pinnacle of Android security. We interviewed Daniel Micay, Copperhead's Chief Technology Officer (CTO) and a contributor to the AOSP, to see why his company believes the Priv isn't as secure as everyone makes it out to be.

Tom's Hardware: You said in a rather controversial tweet that the BlackBerry Priv isn't "at the forefront of Android security," because it hasn’t adopted the security improvements in Android 6.0. Are you implying Android 6.0 is overall more secure than the BlackBerry Priv custom Android 5.1.1 OS? Are the latest Nexus phones more secure than BlackBerry Priv?

Daniel Micay: Nexus phones are more secure than the BlackBerry Priv because Android 6.0 offers some security improvements over 5.1.1. That applies to both the new devices (Nexus 5x and Nexus 6p) and the older devices that are still supported with OS upgrades.

If BlackBerry had significantly hardened 5.1.1, it would be a different story. However, they haven't made any substantial improvements. Nexus devices also already had monthly security updates before the release of the Priv, and it isn't yet clear that BlackBerry is able to deliver on their promise across carriers. Samsung has also made a commitment to deliver monthly updates, but that's different than delivering on it.

TH: What are the enhancements you think BlackBerry did to the Android kernel, and what do they mean for users?

DM: They have the PAX_USERCOPY feature from PaX to provide detection of buffer overflows for some copies to and from the kernel. They also have the PAX_PAGEEXEC feature, but it's not very useful on an architecture with NX support like ARM where it doesn't need to provide emulation of the feature. It simply turns a violation of the no-execute permissions into an unrecoverable failure.

They're not claiming to have a Grsecurity kernel because usage of the trademark requires something up to the standards of the grsecurity developers. There's no official / maintained patch for Android's 3.10 Linux kernel, and they also don't have 99 percent of the features enabled. The grsecurity patch offers the benefit of having many backported security fixes and a steady stream of improvements, but that only applies to the maintained releases.

BlackBerry made their own changes to the kernel too, but none of these appears to be useful. They're duplicating the access control features that are already provided via Android's full system SELinux policy.

On the other hand, it doesn't appear that they've done much to harden userspace, and that's arguably even more important due to remote code execution (RCE) vulnerabilities being more serious than the local privilege escalation issues commonly found in the kernel. Hardening the kernel won't really do anything to mitigate any of the recent RCE bugs like all of the issues in libstagefright and libutils. It does help to contain the attacker once they've successfully gained control over a process, since a kernel exploit can be used to escape from a sandbox.

TH:Why do you think they are not sufficient compared to the improvements in Android 6.0?

DM: There's really not much that they actually did, and Google's security team wasn't just sitting still for a year.

TH: Would BlackBerry Priv’s security enhancements have prevented the Stagefright exploits?

DM: No. They don't appear to have done any work relevant to those.

Some of those vulnerabilities were prevented by the userspace hardening features in CopperheadOS such the 2 critical libutils heap overflows we reported and the one reported by Joshua Drake from Zimperium. Most memory corruption bugs will be significantly harder to exploit in CopperheadOS even if they aren't caught by a specific feature. Among other things relevant to memory corruption bugs: PaX's improved implementation of ASLR, various hardening features from OpenBSD malloc (rather than Android's very exploit-friendly jemalloc allocator) and other improvements to features like ASLR in userspace, like library isolation.

Google is enabling automated integer overflow checking for libstagefright and the other audio/video libraries in the development branch, and we'll likely backport a lot of that as we have with the similar work elsewhere. Since moving to 6.0 is in-progress, that will be approached after we're migrated over. That feature would have been able to prevent most of the libstagefright vulnerabilities.

TH:You’ve open sourced your own alpha-stage CopperheadOS ROM, which is based on Android 5.1.1. Some have said that it’s hypocritical of you to criticize BlackBerry Priv because of this. What do you say to that?

DM: I don't think it's hypocritical. The criticism of BlackBerry was that they are claiming to be leading the way on the security front when it is really not the case. CopperheadOS is carefully marked as being in a very early alpha state right now. All of our work is open source, and a subset of it has been successfully contributed to AOSP. Some of those changes shipped with 6.0. On the other hand, BlackBerry's operating system appears to be closed source, other than the kernel that they're required to release due to the GPL2. Even if they had done substantial work, it wouldn't be moving Android's security forwards in the rest of the ecosystem.

In the future, we can backport important security features to the version of the operating system we're using. It wouldn't be very sensible to spend more of our time doing that right now. It's still in alpha, so developing new features and contributing as much as possible to the Android Open Source Project makes more sense. There's long term value in new features, while backporting only offers benefits until it is moved along to the next version.

Basing it on CyanogenMod will mean new versions take a few extra months to arrive, while using the raw Android Open Source Project code would avoid that. However, basing it on AOSP would limit it to Nexus devices without extra work and would end up resulting in the proprietary Google Play components being much more important. CyanogenMod tends to fill holes left by the migration of components into Google Play. Their in-progress browser based on Chromium is a great example. This isn't set in stone: It can be changed before a stable release, and using AOSP might end up being the only way to make it stable enough.

That said, CopperheadOS does have backports of 6.0 security features, and features that are not yet in 6.0 from master. It's also starting to be the case that many of the security improvements in the Android Open Source Project are the changes we've submitted or steered in the right direction. And the hardening features it already has are substantial.

TH:What are some of the enhancements you’re doing to your own kernel?

DM: CopperheadOS has a port of PaX with more of the features enabled. It has improved Address Space Layout Randomization (PAX_ASLR, PAX_RANDUSTACK, PAX_RANDMMAP), prevention of code injection (PAX_MPROTECT), and more of the kernel self-protection features enabled: PAX_USERCOPY, PAX_REFCOUNT, PAX_MEMORY_SANITIZE along with PAX_KERNEXEC and PAX_MEMORY_UDEREF for the upcoming Nexus 6 release). It has a custom system for setting fine-grained PaX exceptions for Android apps so it can actually have the features enabled for most apps, too.

The OS also offers a setting for MAC randomization (enabled by default) which is implemented in the kernel, but it could also be implemented in userspace.

Most of the work has been on hardening userspace rather than hardening the kernel. The technical overview has good coverage of these features and is mostly up-to-date.

TH: Which of them are already in Android 6.0 and which aren’t?

DM: None of the kernel improvements are present in Android 6.0 yet. Google is working on improving the kernel's ASLR implementation in the development branch, but it's not yet comparable to PaX.

In userspace, some of our _FORTIFY_SOURCE (buffer overflow detection) improvements made it into 6.0, and lots of these will be part of the next release, among other improvements.

TH: What kind of protections do your additional enhancements offer?

DM: Some bugs can't be exploited anymore, and most bugs are significantly harder to exploit. Beyond the low-level hardening, which is most of the work, there are also high-level enhancements like properly integrated support for setting a separate encryption and lockscreen password. Also lots of changes to the default settings to make things more secure and private by default.

TH: Have any of your enhancements been adopted by AOSP or will be in the future?

DM: [Here's a list of changes that were submitted.] Most of those have been merged already, and some are waiting for review or other changes. It's a small subset of the total work in CopperheadOS, but the intention is to upstream more in the future. There have also been contributions in terms of design suggestions, rather than just in terms of contributed code. For example, AOSP adopted setjmp register mangling (a memory corruption exploit mitigation) and hidepid=2 (hiding lots of process information between apps) based on our suggestions.

Contributing code upstream gets it reviewed by Google, so they can suggest their own improvements. It also means it's not going to need to be fixed if conflicting changes occur, since it's maintained as part of AOSP. Anyone making substantial improvements to Android would end up sending patches upstream for bugs and other issues that they're finding, even if they don't want to take advantage of upstreaming features. For example, four sets of vulnerabilities (two critical severity, one low, one high) were found as part of the regular CopperheadOS development, along with various issues that were not vulnerabilities.

TH: Why can’t you port the whole or most of the Grsecurity patchset to Android? Would that break too many things? If it’s a question of funding or development time, would Google be able to do it?

DM: Android devices are stuck with 3.4 and 3.10 kernels with many out-of-tree vendor drivers. The kernels aren't supported by the stable grsecurity patch (3.14). Funding could be provided to grsecurity in order to align a new stable patch, with the next kernel version adopted by Android, and that would go a long way to solving this problem.

Additionally, BlackBerry's device uses a 64-bit ARM CPU, and Grsecurity is not really ported to that architecture yet. The most meaningful features are not available. It's another example of work that needs to be funded, although some of the simple features would be easy enough to port (but BlackBerry didn't do it).

TH: Does CopperheadOS work with the Play Store or F-Droid? Have there been any compromises in security to enable them?

DM: CopperheadOS currently ships with F-Droid as a system application. It implies some trust in the F-Droid developers, so that essentially makes it a security compromise. Down the road, we could offer specialized builds of the OS with only the necessary apps for a given use case and potentially more aggressive security features due to not needing to preserve compatibility with third party apps.

CopperheadOS supports installing Google Play components just as CyanogenMod does, but it's not ever going to be built-in. It goes out of the way to preserve compatibility with it. Google Play adds a lot of attack surface, and many users don't want to hand over control of their device to Google.

TH: When can we expect CopperheadOS to be a daily driver ROM for the Nexus 5? Will any other devices be supported in the future?

DM: It currently supports the Nexus 5, Samsung Galaxy S4 and Nexus 9. It will support the Nexus 6 in the near future, followed by the Nexus 5x and Nexus 6p. There are no plans to add support for other devices. Each supported device adds more time testing and debugging device-specific problems, such as memory corruption bugs detected in device-specific code by OpenBSD malloc. Each one also needs a port of PaX. The main issue right now is simply time required to build ROMs for each device, but that can be solved by throwing money at the problem (i.e., a fancy build server).

It's close to having no known issues not present in CyanogenMod itself, but that's not enough. The builds are currently run through basic tests before uploading, and that needs to be replaced with running the full suite of tests for each release.

TH: Where do you think Android security should go in the future? What would be necessary to happen for Android to be considered one of the most secure operating systems around, and how feasible would that be?

DM: Android on Nexus devices, and other devices, is quite a different beast due to the availability of updates and the lack of poor quality vendor modifications. Those problems are often discussed and [are] not particularly interesting, so I'll focus only on Nexus devices.

Android is already a leader when it comes to access control. It ships with an incredibly well-crafted full system SELinux policy. There are no unconfined processes on the system, and any permissions that aren't required end up being removed. Android is also improving SELinux for other Linux distributions, with features like the ioctl filtering introduced in 6.0 (kernel attack surface reduction). The willingness to make backwards incompatible changes to improve the system's access control means that the mistakes of the past are being corrected. This is where mobile operating systems are way ahead of traditional ones, and Android is particularly good at it. Android 6.0 also leapfrogged both iOS and CyanogenMod when it comes to user control over permissions.

On the other hand, Android isn't really a leader when it comes to other aspects of security. This is starting to change in the development branch, where a lot of work is going into enabling automatic integer overflow checking for C and C++ code. There's a lot more that can be done here, but a lot of it involves making performance sacrifices, so there's a lot more room to do it in a more security-focused OS like CopperheadOS. Android's code also needs a lot of improvement, both via cleaning it up and modernizing it, and more focused efforts to find bugs via auditing and fuzzing. It's not particularly bad compared to other software projects, though. Despite all of the attention directed at the stagefright library, it is really not much worse than alternatives like FFmpeg (if at all) and is quickly improving.

Android does already enable more exploit mitigation features than other mainstream Linux distributions (stack smashing protection, full ASLR and full RELRO across the board without exceptions, etc.), but it's comparable to the mitigations enabled by Apple in iOS and lags behind the exploit mitigations adopted by Microsoft's operating systems. The standard C library (Bionic) is more secure than the traditional glibc implementation used on Linux thanks to being pretty close to a port of the OpenBSD libc to Linux with additional hardening features.

______________________________________________________________________

Lucian Armasu joined Tom’s Hardware in early 2014. He writes news stories on mobile, chipsets, security, privacy, and anything else that might be of interest to him from the technology world. Outside of Tom’s Hardware, he dreams of becoming an entrepreneur.

You can follow him at @lucian_armasu. Follow us on Facebook, Google+, RSS, Twitter and YouTube.