Posted by Gian G Spicuzza, Android Security team
Android Oreo is stuffed full of security enhancements. Over the past few months,
we've covered how we've improved the security of the Android platform and its
applications: from href="https://android-developers.googleblog.com/2017/08/making-it-safer-to-get-apps-on-android-o.html">making
it safer to get apps, dropping href="https://android-developers.googleblog.com/2017/04/android-o-to-drop-insecure-tls-version.html">insecure
network protocols, providing more href="https://android-developers.googleblog.com/2017/04/changes-to-device-identifiers-in.html">user
control over identifiers, href="https://android-developers.googleblog.com/2017/08/hardening-kernel-in-android-oreo.html">hardening
the kernel, href="https://android-developers.googleblog.com/2017/07/shut-hal-up.html">making
Android easier to update, all the way to href="https://android-developers.googleblog.com/2017/06/2017-android-security-rewards.html">doubling
the Android Security Rewards payouts. Now that Oreo is out the door, let's
take a look at all the goodness inside.
Expanding support for hardware security
Android already supports href="https://source.android.com/security/verifiedboot/">Verified Boot,
which is designed to prevent devices from booting up with software that has been
tampered with. In Android Oreo, we added a reference implementation for Verified
Boot running with href="https://source.android.com/devices/architecture/treble">Project
Treble, called Android Verified Boot 2.0 (AVB). 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.
Pixel 2 and Pixel 2 XL come with this protection and we recommend all device
manufacturers add this feature to their new devices.
Oreo also includes the new href="https://android-review.googlesource.com/#/c/platform/hardware/interfaces/+/527086/-1..1/oemlock/1.0/IOemLock.hal">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.
Speaking of hardware, we've invested support in tamper-resistant hardware, such
as the href="https://android-developers.googleblog.com/2017/11/how-pixel-2s-security-module-delivers.html">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.
While the new Pixel devices have the special security module, all new href="https://www.android.com/gms/">GMS devices shipping with Android Oreo
are required to implement href="https://android-developers.googleblog.com/2017/09/keystore-key-attestation.html">key
attestation. This provides a mechanism for strongly href="https://source.android.com/security/keystore/attestation#id-attestation">attesting
IDs such as hardware identifiers.
We added new features for enterprise-managed devices as well. In work profiles,
encryption keys are now ejected from RAM when the profile is off or when your
company's admin remotely locks the profile. This helps secure enterprise data at
rest.
Platform hardening and process isolation
As part of href="https://android-developers.googleblog.com/2017/05/here-comes-treble-modular-base-for.html">Project
Treble, the Android framework was re-architected to make updates easier and
less costly for device manufacturers. This separation of platform and
vendor-code was also designed to improve security. Following the href="https://en.wikipedia.org/wiki/Principle_of_least_privilege">principle of
least privilege, these HALs run in their href="https://android-developers.googleblog.com/2017/07/shut-hal-up.html">own
sandbox and only have access to the drivers and permissions that are
absolutely necessary.
Continuing with the href="https://android-developers.googleblog.com/2016/05/hardening-media-stack.html">media
stack hardening in Android Nougat, most direct hardware access has been
removed from the media frameworks in Oreo resulting in better isolation.
Furthermore, we've enabled Control Flow Integrity (CFI) across all media
components. Most vulnerabilities today are exploited by subverting the normal
control flow of an application, instead changing them to perform arbitrary
malicious activities with all the privileges of the exploited application. CFI
is a robust security mechanism that disallows arbitrary changes to the original
control flow graph of a compiled binary, making it significantly harder to
perform such attacks.
In addition to these architecture changes and CFI, Android Oreo comes with a
feast of other tasty platform security enhancements:
- href="https://android-developers.googleblog.com/2017/07/seccomp-filter-in-android-o.html">Seccomp
filtering: makes some unused syscalls unavailable to apps so that
they can't be exploited by potentially harmful apps.
- Hardened
usercopy: A recent href="https://events.linuxfoundation.org/sites/events/files/slides/Android-%20protecting%20the%20kernel.pdf">survey
of security bugs on Android
revealed that invalid or missing bounds checking was seen in approximately 45%
of kernel vulnerabilities. We've backported a bounds checking feature 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.
App security and device identifier changes
Android
Instant Apps run in a restricted sandbox which limits permissions and
capabilities such as reading the on-device app list or transmitting cleartext
traffic. Although introduced during the Android Oreo release, Instant Apps
supports devices running href="https://www.android.com/versions/lollipop-5-0/">Android Lollipop and
later.
In order to handle untrusted content more safely, we've href="https://android-developers.googleblog.com/2017/06/whats-new-in-webview-security.html">isolated
WebView by splitting the rendering engine into a separate process and
running it within an isolated sandbox that restricts its resources. WebView also
supports Safe Browsing to protect
against potentially dangerous sites.
Lastly, we've made href="https://android-developers.googleblog.com/2017/04/changes-to-device-identifiers-in.html">significant
changes to device identifiers to give users more control, including:
- Moving the static Android ID and Widevine values to an
app-specific value, which helps limit the use of device-scoped non-resettable
IDs.
- In accordance with href="https://tools.ietf.org/html/rfc7844#section-3.7">IETF RFC 7844
anonymity profile, net.hostname is now empty and the DHCP client no
longer sends a hostname.
- For apps that require a device ID, we've built a
Build.getSerial()
API and protected it behind a permission.
- Alongside security researchers1, we designed a robust MAC address
randomization for Wi-Fi scan traffic in various chipsets firmware.
Android Oreo brings in all of these improvements, and href="https://www.android.com/versions/oreo-8-0/">many more. As always, we
appreciate feedback and welcome suggestions for how we can improve Android.
Contact us at security@android.com.
_____________________________________________________________________
1: Glenn Wilkinson and team at Sensepost, UK, Célestin Matte, Mathieu Cunche:
University of Lyon, INSA-Lyon, CITI Lab, Inria Privatics, Mathy Vanhoef, KU
Leuven
