Android Oreo's Double Stuffed Security enhancements detailed by Google

Representational image: Secure Oreo

Highlights 

• Google develops Android Verified Boot 2.0 with Project Treble
• Android Oreo includes new OEM Lock Hardware Abstractions Layer(HAL)
• Google implements Control Flow Integration (CFI) and process isolation

Google has detailed all the key security enhancements that it has designed for Android Oreo. The latest Android platform is already running on a list of mobile devices including the recent Pixel and Nexus models - but as per the latest November figures, it comprises 0.5 percent of active Android devices.

Android Marshmallow and Nougat already added few tidbits of security on devices. But with Android Oreo, Google has provided a new reference implementation of its Verified Boot that is designed to prevent devices from booting up with tampered software. The reference implementation, called Android Verified Boot 2.0(AVB), runs with Project Treble to enable security updates. AVB has a couple of cool features to make updates easier and more secure, such as a common footer format and rollback protection. Rollback protection is designed to prevent a device to boot if downgraded to an older OS version, which could be vulnerable to an exploit. To do this, the devices save the OS version using either special hardware or by having the Trusted Execution Environment (TEE) sign the data. Initially, Google's Pixel 2 and Pixel 2 XL are available with the newest development, though Google recommends all device manufacturers to add the same feature to their new devices.

Oreo also includes the new OEM Lock Hardware Abstraction Layer (HAL) that gives device manufacturers more flexibility for how they protect whether a device is locked, unlocked, or unlockable. For example, the new Pixel phones use this HAL to pass commands to the bootloader. The bootloader analyzes these commands the next time the device boots and determines if changes to the locks, which are securely stored in Replay Protected Memory Block (RPMB), should happen. If your device is stolen, these safeguards are designed to prevent your device from being reset and to keep your data secure. This new HAL even supports moving the lock state to dedicated hardware which may be present to provide outstanding protection from attacks.Talking about Google itself, the company says to have invested in some tamper-resistant hardware, like the security module found in every Pixel 2 and Pixel 2 XL. This physical chip prevents many software and hardware attacks and is also resistant to physical penetration attacks. The security module prevents deriving the encryption key without the device's passcode and limits the rate of unlock attempts, which makes many attacks infeasible due to time restrictions. The all new HAL supports such standalone dedicated security hardware and hence can take full advantage of these.

Android Oreo also enables an enhanced isolation by removing direct hardware access from the default media frameworks. Similarly, Google has enabled Control Flow Integration (CFI) across all media components to disallow arbitrary changes to the original control flow graph to make it harder for attackers to perform malicious activities. Additionally, Google has isolated WebView, media frameworks and HALs by splitting the rendering engine into a separate process and running the same in an isolated sandbox powered by Android's native JVM to restrict external resources.

This way such processes have limited power and they have access to only much required drivers.

In addition to these architecture changes and CFI, Android Oreo comes with a feast of other tasty platform security enhancements:

• Seccomp filtering: makes some unused syscalls unavailable to apps so that they can't be exploited by potentially harmful apps.
• Hardened usercopy a bounds checking feature is now backported to Android kernels 3.18 and above, which makes exploitation harder while also helping developers spot issues and fix bugs in their code.
• Privileged Access Never (PAN) emulation: Also backported to 3.18 kernels and above, this feature prohibits the kernel from accessing user space directly and ensures developers utilize the hardened functions to access user space.
• Kernel Address Space Layout Randomization (KASLR): Although Android has supported userspace Address Space Layout Randomization (ASLR) for years, we've backported KASLR to help mitigate vulnerabilities on Android kernels 4.4 and newer. KASLR works by randomizing the location where kernel code is loaded on each boot, making code reuse attacks probabilistic and therefore more difficult to carry out, especially remotely.

Source : Android developers blog.