Double Stuffed Security in Android Oreo

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 making
it safer to get apps
, dropping insecure
network protocols
, providing more user
control over identifiers
, hardening
the kernel
, making
Android easier to update
, all the way to 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 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 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 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 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 GMS devices shipping with Android Oreo
are required to implement key
attestation
. This provides a mechanism for strongly 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 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 principle of
least privilege
, these HALs run in their own
sandbox
and only have access to the drivers and permissions that are
absolutely necessary.

Continuing with the 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:

  • Seccomp
    filtering
    : makes some unused syscalls unavailable to apps so that
    they can’t be exploited by potentially harmful apps.
  • Hardened
    usercopy
    : A recent 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 Android Lollipop and
later.

In order to handle untrusted content more safely, we’ve 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 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 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 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

Android 8.1 Developer Preview

Posted by Dave Burke, VP of Engineering

Today we’re giving you an early look at Android 8.1. This update to Android Oreo includes a set of targeted enhancements including optimizations for Android Go (for devices with 1GB or less of memory) and a new Neural Networks API to accelerate on-device machine intelligence. We’ve also included a few smaller enhancements to Oreo in response to user and developer feedback.

We’re bringing you this Developer Preview so you can get your apps ready; we’ve already been helping device makers prepare for this new version. We recommend starting soon — we’re expecting the final public version in December.

It’s easy to get Android 8.1 Developer Preview on your Pixel or Nexus device. Just enroll in the Android Beta Program — you’ll soon receive an over-the-air update to Android 8.1 beta. If you enrolled previously, you’re all set, there’s no need to re-enroll. The Developer Preview will be available for Pixel 2 and Pixel 2 XL devices, as well as for Pixel, Pixel XL, Pixel C, Nexus 5X, Nexus 6P, and the Android emulator.

What’s in Android 8.1?

Android 8.1 includes select new features and developer APIs (API level 27), along with the latest optimizations, bug fixes, and security patches. Some of the new APIs include:

  • Android Go memory optimizations and targeting — Android 8.1 includes a set of memory optimizations for Android Go configurations (1GB or less of memory). We’ve added new hardware feature constants so you can now target the distribution of your apps and APK splits to normal or low-RAM devices running Android 8.1 and later.
  • Neural Networks API — as part of our efforts to bring machine intelligence to Android, we’ve added a Neural Networks API via the NDK. It enables hardware-accelerated inference operations on supported devices. We designed the Neural Networks API as a foundational layer for ML frameworks like TensorFlow Lite — Google’s upcoming cross-platform ML framework for mobile — as well as Caffe2 and others. Stay tuned for TensorFlow Lite announcements.
  • Autofill enhancements — we’ve made it easier for password managers and other Autofill services to use the Autofill framework. For example, we’ve added support for more UI customization of the Save dialog, as well as setAutofillOptions() for users to set credit card expiration using a spinner.
  • Shared memory API — this new API lets apps allocate shared memory for faster access to common data. Apps can map anonymous shared memory and manage protection controls using the SharedMemory API. The API is parcelable, AIDL friendly, and exposes useful features like removing write permissions.

Take a look at Android 8.1 site for more information, including the diff report and updated API reference docs.

Test your apps on Android 8.1

With the consumer launch coming in December, it’s important to test your current app now. This gives users a seamless transition to Android 8.1 when it arrives on their devices.

Just enroll your eligible device in Android Beta to get the latest update, then install your app from Google Play and test. If you don’t have a Pixel or Nexus device, you can set up an Android 8.1 emulator for testing instead. If you notice any issues, fix them and update your app in Google Play right away — without changing the app’s platform targeting.

Build with new features and APIs

When you’re ready, take advantage of the new features and APIs in Android 8.1, which we’ve already finalized as API Level 27. For an overview of what’s new, take a look at Android 8.1 for Developers. You can also extend your apps with established Android Oreo features as well, see the Android Oreo site for details.

If your app uses forms, make sure to test them with autofill so that users can take advantage of this convenient feature. Enable “Autofill with Google” or a similar service in Settings and test the form fills to make sure they work as expected. We strongly recommend providing explicit hints about your fields, and also associating your website and mobile app, so that logins can be shared between them.

Speed your development with Android Studio

To build with Android 8.1, we recommend updating to Android Studio 3.0, which is now available from the stable channel. On top of the new app performance profiling tools, support for the Kotlin programming language, and Gradle build optimizations, Android Studio 3.0 makes it easier to develop with Android Oreo features like Instant Apps, XML Fonts, downloadable fonts, and adaptive icons.

We also recommend updating to the Android Support Library 27.0.0, which is available from Google’s Maven repository. New in this version are: a ContentPager library for efficiently loading “paged” data on a background thread; ViewCompat wrappers for Autofill methods; an AmbientMode headless fragment that improves Wear ambient mode support, fullscreen Trusted Web Activities, and more. See the version notes for more information.

You can update your project’s compileSdkVersion to API 27 to compile against the official Android 8.1 APIs. We also recommend updating your app’s targetSdkVersion to API 27 to test with compatibility behaviors disabled. See the this guide for details on how to set up your environment to build with Android 8.1.

Publish your updates to Google Play

The Android 8.1 APIs are already final, so we’ve opened Google Play for apps compiled against or targeting API level 27. When you’re ready, you can publish your APK updates in your alpha, beta, or production channels. Make sure that your updated app runs well on Android 8.1 as well as older versions. We recommend using Google Play’s beta testing feature to run an alpha test on small group of users, then run a much larger open beta test. When you’re ready to launch your update, you can use a staged rollout. We’re looking forward to seeing your app updates!

Give us your feedback!

As always, your feedback is crucial, so please let us know what you think. We’ve set up different hotlists where you report Android platform and tools issues, app compatibility issues, and third-party SDKs and tools issues. We also have a new hotlist for Neural Networks API issues.

You can also give us feedback through the Android Developer community or Android Beta community as we work towards the consumer release in December.

Hardening the Kernel in Android Oreo

Posted by Sami Tolvanen, Senior Software Engineer, Android Security

The hardening of Android’s userspace has increasingly made the underlying Linux
kernel a more attractive target to attackers. As a result, more than a third of
Android security bugs were found in the kernel last year. In Android 8.0 (Oreo),
significant effort has gone into hardening the kernel to reduce the number and
impact of security bugs.

Android
Nougat
worked to protect the kernel by isolating it from userspace processes
with the addition of SELinux ioctl filtering and requiring seccomp-bpf support,
which allows apps to filter access to available system calls when processing
untrusted input. Android 8.0 focuses on kernel self-protection with four
security-hardening features backported from upstream Linux to all Android
kernels supported in devices that first ship with this release.

Hardened usercopy

Usercopy functions are used by the kernel to transfer data from user space to
kernel space memory and back again. Since 2014, missing or invalid bounds
checking has caused about 45% of Android’s kernel vulnerabilities. Hardened usercopy adds bounds
checking to usercopy functions, which helps developers spot misuse and fix bugs
in their code. Also, if obscure driver bugs slip through, hardening these
functions prevents the exploitation of such bugs.

This feature was
introduced
in the upstream kernel version 4.8, and we have backported it to
Android kernels 3.18 and above.

int buggy_driver_function(void __user *src, size_t size)
{
    /* potential size_t overflow (don’t do this) */
    u8 *buf = kmalloc(size * N, GPF_KERNEL);
    …
    /* results in buf smaller than size, and a heap overflow */
    if (copy_from_user(buf, src, size))
    return -EFAULT;

    /* never reached with CONFIG_HARDENED_USERCOPY=y */
}

An example of a security issue that hardened usercopy prevents.

Privileged Access Never (PAN) emulation

While hardened usercopy functions help find and mitigate security issues, they
can only help if developers actually use them. Currently, all kernel code,
including drivers, can access user space memory directly, which can lead to
various security issues.

To mitigate this, CPU vendors have introduced features such as Supervisor Mode
Access Prevention (SMAP) in x86 and Privileged Access Never (PAN) in ARM v8.1.
These features prevent the kernel from accessing user space directly and ensure
developers go through usercopy functions. Unfortunately, these hardware features
are not yet widely available in devices that most Android users have today.

Upstream Linux introduced software emulation for PAN in kernel version 4.3
for ARM
and 4.10 in ARM64. We
have backported both features to Android kernels starting from 3.18.

Together with hardened usercopy, PAN emulation has helped find and fix bugs in
four kernel drivers in Pixel devices.

int buggy_driver_copy_data(struct mydata *src, void __user *ptr)
{
    /* failure to keep track of user space pointers */
    struct mydata *dst = (struct mydata *)ptr;
    …
    /* read/write from/to an arbitrary user space memory location */
    dst->field = … ;    /* use copy_(from|to)_user instead! */
    …
    /* never reached with PAN (emulation) or SMAP */
}

An example of a security issue that PAN emulation mitigates.

Kernel Address Space Layout Randomization (KASLR)

Android has included support for Address Space Layout Randomization (ASLR) for
years. Randomizing memory layout makes code reuse attacks probabilistic and
therefore more difficult for an attacker to exploit, especially remotely.
Android 8.0 brings this feature to the kernel. While Linux has supported KASLR on x86 since version 3.14, KASLR for ARM64 has only been
available upstream since Linux 4.6. Android 8.0 makes KASLR available in Android
kernels 4.4 and newer.

KASLR helps mitigate kernel vulnerabilities by randomizing the location where
kernel code is loaded on each boot. On ARM64, for example, it adds 13–25 bits of
entropy depending on the memory configuration of the device, which makes code
reuse attacks more difficult.

Post-init read-only memory

The final hardening feature extends existing memory protections in the kernel by
creating a memory region that’s marked read-only after the kernel has been
initialized. This makes it possible for developers to improve protection on data
that needs to be writable during initialization, but shouldn’t be modified after
that. Having less writable memory reduces the internal attack surface of the
kernel, making exploitation harder.

Post-init read-only memory was
introduced in upstream kernel version 4.6 and we have backported it to Android
kernels 3.18 and newer. While we have applied these protections to some data
structures in the core kernel, this feature is extremely useful for developers
working on kernel drivers.

Conclusion

Android Oreo includes mitigations for the most common source of security bugs in
the kernel. This is especially relevant because 85% of kernel security bugs in
Android have been in vendor drivers that tend to get much less scrutiny. These
updates make it easier for driver developers to discover common bugs during
development, stopping them before they can reach end user devices.

Making it safer to get apps on Android O

Posted by Edward Cunningham. Product Manager, Android Security

Eagle-eyed users of Android O will have noticed the absence of the ‘Allow
unknown sources’ setting, which has existed since the earliest days of Android
to facilitate the installation of apps from outside of Google Play and other
preloaded stores. In this post we’ll talk about the new Install unknown
apps
permission and the security benefits it brings for both Android
users and developers.

Earlier this year we introduced Google Play
Protect
– comprehensive security services that are always at work to protect
your device from harm. Google Play continues to be one of the safest places for
Android users to download their apps, with the majority of Potentially Harmful
Apps (PHAs) originating from third-party sources.

A common strategy employed by PHA authors is to deliver their apps via a hostile
downloader. For example, a gaming app might not contain malicious code but
instead might notify the user to install a PHA that masquerades as an important
security update. (You can read more about hostile downloaders in the Android
Security 2016 Year in Review
). Users who have enabled the installation of
apps from unknown sources leave themselves vulnerable to this deceptive
behavior.

Left (pre-Android O): The install screen for a PHA masquerading as a system
update.
Right (Android O): Before the PHA is installed, the user must first grant
permission to the app that triggered the install.

In Android O, the Install unknown apps permission makes it
safer to install apps from unknown sources. This permission is tied to the app
that prompts the install— just like other runtime permissions—and ensures that
the user grants permission to use the install source before it can prompt the
user to install an app. When used on a device running Android O and higher,
hostile downloaders cannot trick the user into installing an app without having
first been given the go-ahead.

This new permission provides users with transparency, control, and a streamlined
process to enable installs from trusted sources. The Settings app shows the list
of apps that the user has approved for installing unknown apps. Users can
revoke the permission for a particular app at any time.

At any time, users can review the apps that they’ve allowed for installing
unknown apps. To make the permission-granting process easier, app developers can
choose to direct users to their permission screen as part of the setup
flow.

Developer changes

To take advantage of this new behavior, developers of apps that require the
ability to download and install other apps via the Package Installer may need to
make some changes. If an app uses a targetSdkLevel of 26 or above
and prompts the user to install other apps, the manifest file needs to include
the REQUEST_INSTALL_PACKAGES
permission:

<uses-permission android:name="android.permission.REQUEST_INSTALL_PACKAGES" />

Apps that haven’t declared this permission cannot install other apps, a handy
security protection for apps that have no intention of doing so. You can choose
to pre-emptively direct your users to the Install unknown apps
permission screen using the ACTION_MANAGE_UNKNOWN_APP_SOURCES
Intent action. You can also query the state of this permission using the
PackageManager canRequestPackageInstalls()
API.

Remember that Play policies
still apply to apps distributed on Google Play if those apps can install and
update other apps. In the majority of cases, such behavior is inappropriate; you
should instead provide a deep
link
to the app’s listing on the Play Store.

Be sure to check out the updated publishing
guide
that provides more information about installing unknown apps, and stay
tuned for more posts on security hardening in Android O.