Google seems to be taking Android security even more seriously than it has in the past, after researchers discovered the Stagefright vulnerabilities a year ago. The company has recently announced many new security improvements for Android 7.0 “Nougat” from the hardening of the media server library to more sanitized code and better integrity checking systems.
The latest announcement contains several new kernel security improvements borrowed from the Linux kernel. Google splits these into two categories: memory protections and attack surface reduction.
Memory Protections
Because kernel vulnerabilities can affect other portions of the system, kernel memory protections are important to isolate those vulnerabilities from the userspace.
Mark Memory as Read-Only/No-Execute
This feature segments the memory into isolated logical spaces, where the code is read-only + execute, meaning that new code (such as malware) can’t be written into these spaces, and only the existing code can be read and executed. At least some data sections need to be written, so they are marked no-execute so that if a piece of malware does land in there it can’t execute.
Google based this feature, which you can enable with the configuration option CONFIG_DEBUG_RODATA, on a subset of Grsecurity’s KERNEXEC feature and Qualcomm’s CONFIG_STRICT_MEMORY_RWX feature, and it backported it to Android’s 3.18+ kernel.
Restrict Kernel Access to Userspace
Restricting the kernel access to userspace can make attacks more difficult because attackers have much less control over executable kernel memory, especially if CONFIG_DEBUG_RODATA is enabled. Grsecurity’s UDEREF also inspired this feature. Users can enable it with config option CONFIG_CPU_SW_DOMAIN_PAN.
Improve Protection Against Stack Buffer Overflows
Stack buffer overflows happen when a program writes more data to a call stack buffer than what the system allocated for that buffer. The overflow usually results in corruption of the adjacent data on the stack, and it will cause the program to run incorrectly or crash.
Protecting against stack buffer overflows is a feature of the compiler, and Google added an improved “stack-protector” feature called “stack-protector-strong” to the gcc 4.9 compiler.
Attack Surface Reduction
Attack surface reduction is all about trimming the source code and a system’s unnecessary functionality that may increase the number of potential vulnerabilities. It can also work by limiting how the system exposes certain functionality to users.
Remove Default Access to Debug Features
Debugging tools are meant to be powerful in the sense that they allow developers to do things within the system that they wouldn’t be able to do as regular users. This characteristic also makes debugging tools dangerous from a security perspective if malware starts taking advantage of built-in debug features.
In Android Nougat, the system will block access to the “perf” debug tool by default, but developers can still access it through the adb shell. Google also derived the kernel patch that made perf blocking possible from Grsecurity’s CONFIG_GRKERNSEC_PERF_HARDEN. Daniel Micay, Copperhead’s CTO, added the userspace changes.
Restrict App Access to IOCTL Commands
Most of the kernel vulnerabilities in Android happen through the input/output control (ioctl) syscall. Applications need ioctl commands, but Android can restrict most of them without hurting functionality.
In Android Nougat, only a small whitelist of ioctl commands are available to applications. For some devices, it also restricted GPU ioctls.
Require SECCOMP-BPF
Seccomp is a sandboxing mechanism that can dramatically restrict the kernel's attack surface. Google first introduced the feature on Nexus devices starting with Android 5.0 “Lollipop,” but other manufacturers will also be required to enable it for Android 7.0 and beyond. In Android 7.0, Google is using seccomp for the mediaextractor and mediacodec processes as part of its effort to create stronger sandboxes for the media framework.
Upcoming Features
The Linux community has started focusing more on security as well lately, as Linux security could soon become a life-and-death issue when carmakers start adopting it in autonomous cars.
Independent projects such as Grsecurity have existed for a long time. The Linux community is only now looking at merging some of those features into the upstream Linux kernel, while some distros consider enabling them by default as well for their users.
The Kernel Self Protection Project is one such project that tries to bring subsets of Grsecurity to the upstream Linux kernel. Google seems to be interested in contributing and adopting the Grsecurity-developed features.
Google also appears to be working on using SELinux to sandbox more Android features.
Minijail is a new mechanism that will allow the Android team to apply many containment and sandboxing features offered by the kernel, including seccomp filters and namespaces.
Other projects such as kasan and kcov can help the bug discovery through a process called fuzzing.
As a much more centralized ecosystem compared to the overall Linux ecosystem, Android can afford to adopt any security feature it wants, no matter how restrictive from a functionality point of view, as long as it gives smartphone manufacturers and app developers enough time to adapt to it.
The only real downside to Android’s current security is that manufacturers don’t have to update all of their devices. If they update them at all, they do it only once or twice in a device’s lifecycle, and they may not do it in a timely manner, either.
A solid security architecture can only help so much if certain devices gather a year’s worth of critical vulnerabilities that hackers and malware makers can exploit. This is an issue that Google has yet to solve.
