SafetyNet attestation, a building block for anti-abuse

Posted by Arindam Basu, Borbala Benko, Alan Butler, Edward Cunningham, William Luh



Building innovative security features for Android app developers and their users
continues to be a priority. As part of this effort, we provide SafetyNet
attestation, an API for developers to remotely evaluate whether they are
talking to a genuine Android device.




SafetyNet examines software and hardware information on the device to assess its
integrity. The result is a cryptographically signed statement, attesting basic
properties of the device � such as overall integrity and compatibility with
Android (CTS) � as
well as metadata about your app, such as its package name and signature. The
following JSON snippet shows an example of how the API reports this information:

{
  "nonce": "R2Rra24fVm5xa2Mg",
  "timestampMs": 9860437986543,
  "apkPackageName": "com.package.name.of.requesting.app",
  "apkCertificateDigestSha256": ["base64 encoded, SHA-256 hash of the
                                  certificate used to sign requesting app"],
  "apkDigestSha256": "base64 encoded, SHA-256 hash of the app's APK",
  "ctsProfileMatch": true,
  "basicIntegrity": true,
}

The contents of an example attestation response, providing information about
the calling app and the integrity and compatibility of the device.




The SafetyNet attestation API can help your server distinguish traffic coming
from genuine, compatible Android devices from traffic coming from less-trusted
sources, including non-Android devices. This classification helps you better
understand the risks associated with each device so that you can fine-tune
preventive or mitigative actions in case of abuse or misbehavior.




We encourage developers to use SafetyNet attestations to augment their
anti-abuse strategy. Combine SafetyNet attestation with other signals, such as
your existing device-side signals and behavioral signals about what the user is
trying to do, in order to build robust, multi-tier protection systems.




For further information, check the recently
updated documentation and see the SafetyNet API
Samples on GitHub.

Diverse protections for a diverse ecosystem: Android Security 2016 Year in Review

Posted by Adrian Ludwig & Mel Miller, Android Security Team

Today, we're sharing the third annual Android Security Year In Review, a
comprehensive look at our work to protect more than 1.4 billion Android users
and their data.




Our goal is simple: keep our users safe. In 2016, we improved our abilities to
stop dangerous apps, built new security features into Android 7.0 Nougat, and
collaborated with device manufacturers, researchers, and other members of the
Android ecosystem. For more details, you can read the full
Year in Review report or watch our
webinar.

Protecting you from PHAs

It's critical to keep people safe from Potentially
Harmful Apps (PHAs) that may put their data or devices at risk. Our ongoing
work in this area requires us to find ways to track and stop existing PHAs, and
anticipate new ones that haven't even emerged yet.

Over the years, we've built a variety of systems to address these threats, such
as application analyzers that constantly review apps for unsafe behavior, and
Verify Apps which regularly checks users' devices for PHAs. When these systems
detect PHAs, we warn users, suggest they think twice about downloading a
particular app, or even remove the app from their devices entirely.



We constantly monitor threats and improve our systems over time. Last year's
data reflected those improvements: Verify Apps conducted 750 million daily
checks in 2016, up from 450 million the previous year, enabling us to reduce the
PHA installation rate in the top 50 countries for Android usage.




Google Play continues to be the safest place for Android users to download their
apps. Installs of PHAs from Google Play decreased in nearly every category:

• Now 0.016 percent of installs, trojans dropped by 51.5 percent compared to
  2015
  


• Now 0.003 percent of installs, hostile downloaders dropped by 54.6 percent
  compared to 2015
  


• Now 0.003 percent of installs, backdoors dropped by 30.5 percent compared to
  2015
  


• Now 0.0018 percent of installs, phishing apps dropped by 73.4 percent
  compared to 2015

By the end of 2016, only 0.05 percent of devices that downloaded apps
exclusively from Play contained a PHA; down from 0.15 percent in 2015.




Still, there's more work to do for devices overall, especially those that
install apps from multiple sources. While only 0.71 percent of all Android
devices had PHAs installed at the end of 2016, that was a slight increase from
about 0.5 percent in the beginning of 2015. Using improved tools and the
knowledge we gained in 2016, we think we can reduce the number of devices
affected by PHAs in 2017, no matter where people get their apps.

New security protections in Nougat

Last year, we introduced a
variety of new protections in Nougat, and continued our ongoing work to strengthen
the security of the Linux Kernel.

• Encryption improvements: In Nougat, we introduced
  file-based encryption which enables each user profile on a single device to be
  encrypted with a unique key. If you have personal and work accounts on the same
  device, for example, the key from one account can't unlock data from the other.
  More broadly, encryption of user data has been required for capable Android
  devices since in late 2014, and we now see that feature enabled on over 80
  percent of Android Nougat devices.
  


• New audio and video protections: We did significant work to
  improve
  security and re-architect how Android handles video and audio media. One
  example: We now store different media components into individual sandboxes,
  where previously they lived together. Now if one component is compromised, it
  doesn't automatically have permissions to other components, which helps contain
  any additional issues.
  


• Even more security for enterprise users: We introduced a variety
  of new enterprise security features including "Always On" VPN, which
  protects your data from the moment your device boots up and ensures it isn't
  traveling from a work phone to your personal device via an insecure connection.
  We also added security policy transparency, process logging, improved wifi
  certification handling, and client certification improvements to our growing set of enterprise
  tools.

Working together to secure the Android ecosystem

Sharing information about security threats between Google, device manufacturers,
the research community, and others helps keep all Android users safer. In 2016,
our biggest collaborations were our monthly security updates program and ongoing
partnership with the security research community.




Security updates are regularly highlighted as a pillar of mobile security�and
rightly so. We launched
our monthly security updates program in 2015, following the public
disclosure of a bug in Stagefright, to help accelerate patching security
vulnerabilities across devices from many different device makers. This program
expanded significantly in 2016:

• More than 735 million devices from 200+ manufacturers received a platform
  security update in 2016.
  


• We released monthly Android security updates throughout the year for devices
  running Android 4.4.4 and up�that accounts for 86.3 percent of all active
  Android devices worldwide.
  


• Our carrier and hardware partners helped expand deployment of these updates,
  releasing updates for over half of the top 50 devices worldwide in the last
  quarter of 2016.

We provided monthly security updates for all supported Pixel and Nexus devices
throughout 2016, and we're thrilled to see our partners invest significantly in
regular updates as well. There's still a lot of room for improvement however.
About half of devices in use at the end of 2016 had not received a platform
security update in the previous year. We're working to increase device security
updates by streamlining our security update program to make it easier for
manufacturers to deploy security patches and releasing A/B
updates to make it easier for users to apply those patches.




On the research side, our Android Security Rewards program grew rapidly: we paid
researchers nearly $1 million dollars for their reports in 2016. In
parallel, we worked closely with various security firms to identify and quickly
fix issues that may have posed risks to our users.




We appreciate all of the hard work by Android partners, external researchers,
and teams at Google that led to the progress the ecosystem has made with
security in 2016. But it doesn't stop there. Keeping you safe requires constant
vigilance and effort. We're looking forward to new insights and progress in 2017
and beyond.

Detecting and eliminating Chamois, a fraud botnet on Android

Posted by Security Software Engineers�Bernhard Grill, Megan Ruthven, and Xin Zhao

Google works hard to protect users across a variety of devices and environments. Part of this work involves defending users against Potentially Harmful Applications (PHAs), an effort that gives us the opportunity to observe various types of threats targeting our ecosystem. For example, our security teams recently discovered and defended users of our ads and Android systems against a new PHA family we've named Chamois.



Chamois is an Android PHA family capable of:

• Generating invalid traffic through ad pop ups having deceptive graphics inside the ad


• Performing artificial app promotion by automatically installing apps in the background


• Performing telephony fraud by sending premium text messages


• Downloading and executing additional plugins

Interference with the ads ecosystem

We detected Chamois during a routine ad traffic quality evaluation. We analyzed malicious apps based on Chamois, and found that they employed several methods to avoid detection and tried to trick users into clicking ads by displaying deceptive graphics. This sometimes resulted in downloading of other apps that commit SMS fraud. So we blocked the Chamois app family using Verify Apps and also kicked out bad actors who were trying to game our ad systems.

Our previous experience with ad fraud apps like this one enabled our teams to swiftly take action to protect both our advertisers and Android users. Because the malicious app didn't appear in the device's app list, most users wouldn't have seen or known to uninstall the unwanted app. This is why Google's Verify Apps is so valuable, as it helps users discover PHAs and delete them.

Under Chamois's hood

Chamois was one of the largest PHA families seen on Android to date and distributed through multiple channels. To the best of our knowledge Google is the first to publicly identify and track Chamois.

Chamois had a number of features that made it unusual, including:

• Multi-staged payload: Its code is executed in 4 distinct stages using different file formats, as outlined in this diagram.

This multi-stage process makes it more complicated to immediately identify apps in this family as a PHA because the layers have to be peeled first to reach the malicious part. However, Google's pipelines weren't tricked as they are designed to tackle these scenarios properly.

• Self-protection: Chamois tried to evade detection using obfuscation and anti-analysis techniques, but our systems were able to counter them and detect the apps accordingly.


• Custom encrypted storage: The family uses a custom, encrypted file storage for its configuration files and additional code that required deeper analysis to understand the PHA.


• Size: Our security teams sifted through more than 100K lines of sophisticated code written by seemingly professional developers. Due to the sheer size of the APK, it took some time to understand Chamois in detail.

Google's approach to fighting PHAs

Verify Apps protects users from known PHAs by warning them when they are downloading an app that is determined to be a PHA, and it also enables users to uninstall the app if it has already been installed. Additionally, Verify Apps monitors the state of the Android ecosystem for anomalies and investigates the ones that it finds. It also helps finding unknown PHAs through behavior analysis on devices. For example, many apps downloaded by Chamois were highly ranked by the DOI scorer. We have implemented rules in Verify Apps to protect users against Chamois.

Google continues to significantly invest in its counter-abuse technologies for Android and its ad systems, and we're proud of the work that many teams do behind the scenes to fight PHAs like Chamois.



We hope this summary provides insight into the growing complexity of Android botnets. To learn more about Google's anti-PHA efforts and further ameliorate the risks they pose to users, devices, and ad systems, keep an eye open for the upcoming "Android Security 2016 Year In Review" report.

App Security Improvements: Looking back at 2016

Posted by Rahul Mishra, Android Security Program Manager

In April 2016, the Android Security team described how the Google Play App
Security Improvement (ASI) program has helped developers fix
security issues in 100,000 applications. Since then, we have detected and
notified developers of 11 new security issues and provided developers with
resources and guidance to update their apps. Because of this, over 90,000
developers have updated over 275,000 apps!

ASI now notifies developers of 26 potential security issues. To make this
process more transparent, we introduced a new page where
developers can find information about all these security issues in one place.
This page includes links to help center articles containing instructions and
additional support contacts. Developers can use this page as a resource to learn
about new issues and keep track of all past issues.




Make sure to check out our new Security for Android Developers page, which highlights the latest
security posts, security best
practices documents and security
checklist. These resources are all aimed at improving your understanding of general
security concepts and giving you examples that can help you address app-specific
issues.




How you can help:


For feedback or questions, please reach out to us through the Google PlayDeveloper Help Center.

To report potential security issues in apps, email us at
security+asi@android.com.

Silence speaks louder than words when finding malware

Posted by Megan Ruthven, Software Engineer

In Android Security, we're constantly working to better understand how to make
Android devices operate more smoothly and securely. One security solution
included on all devices with Google Play is Verify apps.
Verify apps checks if there are Potentially Harmful Apps (PHAs) on your device.
If a PHA is found, Verify apps warns the user and enables them to uninstall the
app.

But, sometimes devices stop checking up with Verify apps. This may happen for a
non-security related reason, like buying a new phone, or, it could mean
something more concerning is going on. When a device stops checking up with
Verify apps, it is considered Dead or Insecure (DOI). An app with a high enough
percentage of DOI devices downloading it, is considered a DOI app. We use the
DOI metric, along with the other security systems to help determine if an app is
a PHA to protect Android users. Additionally, when we discover vulnerabilities,
we patch Android devices with our security update system.




This blog post explores the Android Security team's research to identify the
security-related reasons that devices stop working and prevent it from happening
in the future.

Flagging DOI Apps

To understand this problem more deeply, the Android Security team correlates app
install attempts and DOI devices to find apps that harm the device in order to
protect our users.

With these factors in mind, we then focus on 'retention'. A device is considered
retained if it continues to perform periodic Verify apps security check ups
after an app download. If it doesn't, it's considered potentially dead or
insecure (DOI). An app's retention rate is the percentage of all retained
devices that downloaded the app in one day. Because retention is a strong
indicator of device health, we work to maximize the ecosystem's retention rate.




Therefore, we use an app DOI scorer, which assumes that all apps should have a
similar device retention rate. If an app's retention rate is a couple of
standard deviations lower than average, the DOI scorer flags it. A common way to
calculate the number of standard deviations from the average is called a
Z-score. The equation for the Z-score is below.

• N = Number of devices that downloaded the app.
  


• x = Number of retained devices that downloaded the app.
  


• p = Probability of a device downloading any app will be retained.

In this context, we call the Z-score of an app's retention rate a DOI score. The DOI score indicates an app has a statistically significant lower retention rate if the Z-score is much less than -3.7. This means that if the null hypothesis is true, there is much less than a 0.01% chance the magnitude of the Z-score being as high. In this case, the null hypothesis means the app accidentally correlated with lower retention rate independent of what the app does.

This allows for percolation of extreme apps (with low retention rate and high number of downloads) to the top of the DOI list. From there, we combine the DOI score with other information to determine whether to classify the app as a PHA. We then use Verify apps to remove existing installs of the app and prevent future installs of the app.

Difference between a regular and DOI app download on the same device.

Results in the wild

Among others, the DOI score flagged many apps in three well known malware
families� Hummingbad,
Ghost
Push, and Gooligan.
Although they behave differently, the DOI scorer flagged over 25,000 apps in
these three families of malware because they can degrade the Android experience
to such an extent that a non-negligible amount of users factory reset or abandon
their devices. This approach provides us with another perspective to discover
PHAs and block them before they gain popularity. Without the DOI scorer, many of
these apps would have escaped the extra scrutiny of a manual review.

The DOI scorer and all of Android's anti-malware work is one of multiple layers
protecting users and developers on Android. For an overview of Android's
security and transparency efforts, check out our page.

Pixel Security: Better, Faster, Stronger

Posted by Paul Crowley, Senior Software Engineer and Paul Lawrence, Senior Software Engineer

Encryption protects your data if your phone falls into someone else's hands. The
new Google Pixel and Pixel XL are encrypted by default to offer strong data
protection, while maintaining a great user experience with high I/O performance
and long battery life. In addition to encryption, the Pixel phones debuted
running the Android Nougat release, which has even more href="http://android-developers.blogspot.com/2016/09/security-enhancements-in-nougat.html">security
improvements.

This blog post covers the encryption implementation on Google Pixel devices and
how it improves the user experience, performance, and security of the device.

File-Based Encryption Direct Boot experience

One of the security features introduced in Android Nougat was href="https://source.android.com/security/encryption/file-based.html">file-based
encryption. File-based encryption (FBE) means different files are encrypted
with different keys that can be unlocked independently. FBE also separates data
into device encrypted (DE) data and credential encrypted (CE) data.

href="https://developer.android.com/training/articles/direct-boot.html">Direct
boot uses file-based encryption to allow a seamless user experience when a
device reboots by combining the unlock and decrypt screen. For users, this means
that applications like alarm clocks, accessibility settings, and phone calls are
available immediately after boot.

Enhanced with TrustZone� security

Modern processors provide a means to execute code in a mode that remains secure
even if the kernel is compromised. On ARM�-based processors this mode is known
as TrustZone. Starting in Android Nougat, all disk encryption keys are stored
encrypted with keys held by TrustZone software. This secures encrypted data in
two ways:

• TrustZone enforces the href="https://source.android.com/security/verifiedboot/">Verified Boot
  process. If TrustZone detects that the operating system has been modified, it
  won't decrypt disk encryption keys; this helps to secure device encrypted (DE)
  data.
  
• TrustZone enforces a waiting period between guesses at the user credential,
  which gets longer after a sequence of wrong guesses. With 1624 valid four-point
  patterns and TrustZone's ever-growing waiting period, trying all patterns would
  take more than four years. This improves security for all users, especially
  those who have a shorter and more easily guessed pattern, PIN, or
  password.

Encryption on Pixel phones

Protecting different folders with different keys required a distinct approach
from href="http://source.android.com/security/encryption/full-disk.html">full-disk
encryption (FDE). The natural choice for Linux-based systems is the
industry-standard eCryptFS. However, eCryptFS didn't meet our performance
requirements. Fortunately one of the eCryptFS creators, Michael Halcrow, worked
with the ext4 maintainer, Ted Ts'o, to add encryption natively to ext4, and
Android became the first consumer of this technology. ext4 encryption
performance is similar to full-disk encryption, which is as performant as a
software-only solution can be.

Additionally, Pixel phones have an inline hardware encryption engine, which
gives them the ability to write encrypted data at line speed to the flash
memory. To take advantage of this, we modified ext4 encryption to use this
hardware by adding a key reference to the bio structure, within the ext4 driver
before passing it to the block layer. (The bio structure is the basic container
for block I/O in the Linux kernel.) We then modified the inline encryption block
driver to pass this to the hardware. As with ext4 encryption, keys are managed
by the Linux keyring. To see our implementation, take a look at the href="https://android.googlesource.com/kernel/msm/+/android-msm-marlin-3.18-nougat-dr1/fs/ext4/crypto_key.c">source
code for the Pixel kernel.

While this specific implementation of file-based encryption using ext4 with
inline encryption benefits Pixel users, FBE is available in AOSP and ready to
use, along with the other features mentioned in this post.

Keeping Android safe: Security enhancements in Nougat

Posted by Xiaowen Xin, Android Security Team




Over the course of the summer, we previewed a variety of security enhancements in
Android 7.0 Nougat: an increased focus on security with our vulnerability
rewards program, a new Direct
Boot mode, re-architected mediaserver and hardened
media stack, apps that are protected from accidental
regressions to cleartext traffic, an update to the way Android handles trusted
certificate authorities, strict enforcement of verified
boot with error correction, and updates
to the Linux kernel to reduce the attack surface and increase memory
protection. Phew!



Now that Nougat has begun to roll out, we wanted to recap these updates in a
single overview and highlight a few new improvements.

Direct Boot and encryption

In previous versions of Android, users with encrypted devices would have to
enter their PIN/pattern/password by default during the boot process to decrypt
their storage area and finish booting. With Android 7.0 Nougat, we�ve updated
the underlying encryption scheme and streamlined the boot process to speed up
rebooting your phone. Now your phone�s main features, like the phone app and
your alarm clock, are ready right away before you even type your PIN, so people
can call you and your alarm clock can wake you up. We call this feature Direct
Boot.




Under the hood, file-based encryption enables this improved user experience.
With this new encryption scheme, the system storage area, as well as each user
profile storage area, are all encrypted separately. Unlike with full-disk
encryption, where all data was encrypted as a single unit, per-profile-based
encryption enables the system to reboot normally into a functional state using
just device keys. Essential apps can opt-in to run in a limited state after
reboot, and when you enter your lock screen credential, these apps then get
access your user data to provide full functionality.




File-based encryption better isolates and protects individual users and profiles
on a device by encrypting data at a finer granularity. Each profile is encrypted
using a unique key that can only be unlocked by your PIN or password, so that
your data can only be decrypted by you.

Encryption support is getting stronger across the Android ecosystem as well.
Starting with Marshmallow, all capable devices were required to support
encryption. Many devices, like Nexus 5X and 6P also use unique keys that are
accessible only with trusted hardware, such as the ARM TrustZone. Now with 7.0
Nougat, all new capable Android devices must also have this kind of hardware
support for key storage and provide brute force protection while verifying your
lock screen credential before these keys can be used. This way, all of your data
can only be decrypted on that exact device and only by you.

The media stack and platform hardening

In Android Nougat, we�ve both hardened and re-architected
mediaserver, one of the main system services that processes untrusted input.
First, by incorporating integer overflow sanitization, part of Clang�s UndefinedBehaviorSanitizer,
we prevent an entire class of vulnerabilities, which comprise the majority of
reported libstagefright bugs. As soon as an integer overflow is detected, we
shut down the process so an attack is stopped. Second, we�ve modularized the
media stack to put different components into individual sandboxes and tightened
the privileges of each sandbox to have the minimum privileges required to
perform its job. With this containment technique, a compromise in many parts of
the stack grants the attacker access to significantly fewer permissions and
significantly reduced exposed kernel attack surface.




In addition to hardening the mediaserver, we�ve added a large list of
protections for the platform, including:

• Verified Boot: Verified Boot is now strictly enforced to
  prevent compromised devices from booting; it supports error
  correction to improve reliability against non-malicious data corruption.
  


• SELinux: Updated SELinux configuration and increased
  Seccomp coverage further locks down the application sandbox and reduces attack
  surface.
  


• Library load order randomization and improved ASLR:
  Increased randomness makes some code-reuse attacks less reliable.
  


• Kernel
  hardening: Added additional memory protection for newer kernels by
  marking
  portions of kernel memory as read-only, restricting
  kernel access to userspace addresses, and further reducing the existing
  attack surface.
  


• APK signature scheme v2: Introduced a whole-file signature scheme that
  improves verification
  speed and strengthens integrity guarantees.

App security improvements

Android Nougat is the safest and easiest version of Android for application
developers to use.

• Apps that want to share data with other apps now must explicitly opt-in by
  offering their files through a Content
  Provider, like FileProvider.
  The application private directory (usually /data/data/) is now set to
  Linux permission 0700 for apps targeting API Level 24+.
  


• To make it easier for apps to control access to their secure network
  traffic, user-installed certificate authorities and those installed through
  Device Admin APIs are no
  longer trusted by default for apps targeting API Level 24+. Additionally,
  all new Android devices must ship with the same
  trusted CA store.
  


• With Network Security Config, developers can more easily configure network security
  policy through a declarative configuration file. This includes blocking
  cleartext traffic, configuring the set of trusted CAs and certificates, and
  setting up a separate debug configuration.

We�ve also continued to refine app permissions and capabilities to protect you
from potentially harmful apps.

• To improve device privacy, we have further restricted and removed access to
  persistent device identifiers such as MAC addresses.
  


• User interface overlays can no longer be displayed on top of permissions
  dialogs. This �clickjacking� technique was used by some apps to attempt to gain
  permissions improperly.
  


• We�ve reduced the power of device admin applications so they can no longer
  change your lockscreen if you have a lockscreen set, and device admin will no
  longer be notified of impending disable via onDisableRequested().
  These were tactics used by some ransomware to gain control of a
  device.

System Updates

Lastly, we've made significant enhancements to the OTA update system to keep
your device up-to-date much more easily with the latest system software and
security patches. We've made the install time for OTAs faster, and the OTA size
smaller for security updates. You no longer have to wait for the optimizing apps
step, which was one of the slowest parts of the update process, because the new
JIT compiler has been optimized
to make installs and updates lightning fast.


The update experience is even faster for new Android devices running Nougat with
updated firmware. Like they do with Chromebooks, updates are applied in the
background while the device continues to run normally. These updates are applied
to a different system partition, and when you reboot, it will seamlessly switch
to that new partition running the new system software version.




We�re constantly working to improve Android security and Android Nougat brings
significant security improvements across all fronts. As always, we appreciate
feedback on our work and welcome suggestions for how we can improve Android.
Contact us at security@android.com.

Protecting Android with more Linux kernel defenses

Posted by Jeff Vander Stoep, Android Security team

Android relies heavily on the Linux kernel for enforcement of its security
model. To better protect the kernel, we�ve enabled a number of mechanisms within
Android. At a high level these protections are grouped into two
categories�memory protections and attack surface reduction.

Memory protections

One of the major security features provided by the kernel is memory protection
for userspace processes in the form of address space separation. Unlike
userspace processes, the kernel�s various tasks live within one address space
and a vulnerability anywhere in the kernel can potentially impact unrelated
portions of the system�s memory. Kernel memory protections are designed to
maintain the integrity of the kernel in spite of vulnerabilities.

Mark memory as read-only/no-execute

This feature segments kernel memory into logical sections and sets restrictive
page access permissions on each section. Code is marked as read only + execute.
Data sections are marked as no-execute and further segmented into read-only and
read-write sections. This feature is enabled with config option
CONFIG_DEBUG_RODATA. It was put together by Kees Cook and is based on a subset
of Grsecurity�s KERNEXEC feature by Brad
Spengler and Qualcomm�s CONFIG_STRICT_MEMORY_RWX feature by Larry Bassel and
Laura Abbott. CONFIG_DEBUG_RODATA landed in the upstream kernel for arm/arm64
and has been backported to Android�s 3.18+ arm/href="https://android-review.googlesource.com/#/c/174947/">arm64 common
kernel.

Restrict kernel access to userspace

This feature improves protection of the kernel by preventing it from directly
accessing userspace memory. This can make a number of attacks more difficult
because attackers have significantly less control over kernel memory
that is executable, particularly with CONFIG_DEBUG_RODATA enabled. Similar
features were already in existence, the earliest being Grsecurity�s UDEREF. This
feature is enabled with config option CONFIG_CPU_SW_DOMAIN_PAN and was
implemented by Russell King for ARMv7 and backported to href="https://android-review.googlesource.com/#/q/topic:sw_PAN">Android�s
4.1 kernel by Kees Cook.

Improve protection against stack buffer overflows

Much like its predecessor, stack-protector, stack-protector-strong protects
against stack
buffer overflows, but additionally provides coverage for href="https://outflux.net/blog/archives/2014/01/27/fstack-protector-strong/">more
array types, as the original only protected character arrays.
Stack-protector-strong was implemented by Han Shen and href="https://gcc.gnu.org/ml/gcc-patches/2012-06/msg00974.html">added to the gcc
4.9 compiler.

Attack surface reduction

Attack surface reduction attempts to expose fewer entry points to the kernel
without breaking legitimate functionality. Reducing attack surface can include
removing code, removing access to entry points, or selectively exposing
features.

Remove default access to debug features

The kernel�s perf system provides infrastructure for performance measurement and
can be used for analyzing both the kernel and userspace applications. Perf is a
valuable tool for developers, but adds unnecessary attack surface for the vast
majority of Android users. In Android Nougat, access to perf will be blocked by
default. Developers may still access perf by enabling developer settings and
using adb to set a property: �adb shell setprop security.perf_harden 0�.

The patchset for blocking access to perf may be broken down into kernel and
userspace sections. The href="https://android-review.googlesource.com/#/c/234573/">kernel patch is
by Ben Hutchings and is
derived from Grsecurity�s CONFIG_GRKERNSEC_PERF_HARDEN by Brad Spengler. The
userspace changes were href="https://android-review.googlesource.com/#/q/topic:perf_harden">contributed
by Daniel Micay. Thanks to href="https://conference.hitb.org/hitbsecconf2016ams/sessions/perf-from-profiling-to-kernel-exploiting/">Wish
Wu and others for responsibly disclosing security vulnerabilities in perf.

Restrict app access to ioctl commands

Much of Android security model is described and enforced by SELinux. The ioctl()
syscall represented a major gap in the granularity of enforcement via SELinux.
Ioctl command
whitelisting with SELinux was added as a means to provide per-command
control over the ioctl syscall by SELinux.

Most of the kernel vulnerabilities reported on Android occur in drivers and are
reached using the ioctl syscall, for example href="https://source.android.com/security/bulletin/2016-03-01.html#elevation_of_privilege_vulnerability_in_mediatek_wi-fi_kernel_driver">CVE-2016-0820.
Some ioctl commands are needed by third-party applications, however most are not
and access can be restricted without breaking legitimate functionality. In
Android Nougat, only a small whitelist of socket ioctl commands are available to
applications. For select devices, applications� access to GPU ioctls has been
similarly restricted.

Require seccomp-bpf

Seccomp provides an additional sandboxing mechanism allowing a process to
restrict the syscalls and syscall arguments available using a configurable
filter. Restricting the availability of syscalls can dramatically cut down on
the exposed attack surface of the kernel. Since seccomp was first introduced on
Nexus devices in Lollipop, its availability across the Android ecosystem has
steadily improved. With Android Nougat, seccomp support is a requirement for all
devices. On Android Nougat we are using seccomp on the mediaextractor and
mediacodec processes as part of the href="http://android-developers.blogspot.com/2016/05/hardening-media-stack.html">media
hardening effort.

Ongoing efforts

There are other projects underway aimed at protecting the kernel:

• The href="http://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project">Kernel
  Self Protection Project is developing runtime and compiler defenses for the
  upstream kernel.
  
• Further sandbox tightening and attack surface reduction with SELinux is
  ongoing in AOSP.
  
• href="https://www.chromium.org/chromium-os/developer-guide/chromium-os-sandboxing#h.l7ou90opzirq">Minijail
  provides a convenient mechanism for applying many containment and sandboxing
  features offered by the kernel, including seccomp filters and namespaces.
  
• Projects like href="https://www.kernel.org/doc/Documentation/kasan.txt">kasan and href="https://www.kernel.org/doc/Documentation/kcov.txt">kcov help fuzzers
  discover the root cause of crashes and to intelligently construct test cases
  that increase code coverage�ultimately resulting in a more efficient bug hunting
  process.

Due to these efforts and others, we expect the security of the kernel to
continue improving. As always, we appreciate feedback on our work and welcome
suggestions for how we can improve Android. Contact us at href="mailto:security@android.com">security@android.com.

Strictly Enforced Verified Boot with Error Correction

Posted by Sami Tolvanen, Software Engineer

Overview

Android uses multiple layers of protection to keep users safe. One of these
layers is verified
boot, which improves security by using cryptographic integrity checking to
detect changes to the operating system. Android has href="https://g.co/ABH">alerted about system integrity since Marshmallow,
but starting with devices first shipping with Android 7.0, we require verified
boot to be strictly enforcing. This means that a device with a corrupt boot
image or verified partition will not boot or will boot in a limited capacity
with user consent. Such strict checking, though, means that non-malicious data
corruption, which previously would be less visible, could now start affecting
process functionality more.

By default, Android verifies large partitions using the dm-verity kernel driver,
which divides the partition into 4 KiB blocks and verifies each block when read,
against a signed hash tree. A detected single byte corruption will therefore
result in an entire block becoming inaccessible when dm-verity is in enforcing
mode, leading to the kernel returning EIO errors to userspace on verified
partition data access.

This post describes our work in improving dm-verity robustness by introducing
forward error correction (FEC), and explains how this allowed us to make the
operating system more resistant to data corruption. These improvements are
available to any device running Android 7.0 and this post reflects the default
implementation in AOSP that we ship on our Nexus devices.

Error-correcting codes

Using forward error correction, we can detect and correct errors in source data
by shipping redundant encoding data generated using an error-correcting code.
The exact number of errors that can be corrected depends on the code used and
the amount of space allocated for the encoding data.

href="https://en.wikipedia.org/wiki/Reed%E2%80%93Solomon_error_correction">Reed-Solomon
is one of the most commonly used error-correcting code families, and is readily
available in the Linux kernel, which makes it an obvious candidate for
dm-verity. These codes can correct up to ?t/2? unknown errors and up to
t known errors, also called href="https://en.wikipedia.org/wiki/Erasure_code">erasures, when t
encoding symbols are added.

A typical RS(255, 223) code that generates 32 bytes of encoding data for every
223 bytes of source data can correct up to 16 unknown errors in each 255 byte
block. However, using this code results in ~15% space overhead, which is
unacceptable for mobile devices with limited storage. We can decrease the space
overhead by sacrificing error correction capabilities. An RS(255, 253) code can
correct only one unknown error, but also has an overhead of only 0.8%.

An additional complication is that block-based storage corruption often occurs
for an entire block and sometimes spans multiple consecutive blocks. Because
Reed-Solomon is only able to recover from a limited number of corrupted bytes
within relatively short encoded blocks, a naive implementation is not going to
be very effective without a huge space overhead.

Recovering from consecutive corrupted blocks

In the changes we made to href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=a739ff3f543afbb4a041c16cd0182c8e8d366e70">dm-verity
for Android 7.0, we used a technique called interleaving to allow us to recover
not only from a loss of an entire 4 KiB source block, but several consecutive
blocks, while significantly reducing the space overhead required to achieve
usable error correction capabilities compared to the naive implementation.

Efficient interleaving means mapping each byte in a block to a separate
Reed-Solomon code, with each code covering N bytes across the corresponding N
source blocks. A trivial interleaving where each code covers a consecutive
sequence of N blocks already makes it possible for us to recover from the
corruption of up to (255 - N) / 2 blocks, which for RS(255, 223) would
mean 64 KiB, for example.

An even better solution is to maximize the distance between the bytes covered by
the same code by spreading each code over the entire partition, thereby
increasing the maximum number of consecutive corrupted blocks an RS(255, N) code
can handle on a partition consisting of T blocks to ?T/N? � (255 -
N) / 2.

Interleaving with distance D and block size B.

An additional benefit of interleaving, when combined with the integrity
verification already performed by dm-verity, is that we can tell exactly where
the errors are in each code. Because each byte of the code covers a different
source block�and we can verify the integrity of each block using the existing
dm-verity metadata�we know which of the bytes contain errors. Being able to
pinpoint erasure locations allows us to effectively double our error correction
performance to at most ?T/N? � (255 - N) consecutive blocks.

For a ~2 GiB partition with 524256 4 KiB blocks and RS(255, 253), the maximum
distance between the bytes of a single code is 2073 blocks. Because each code
can recover from two erasures, using this method of interleaving allows us to
recover from up to 4146 consecutive corrupted blocks (~16 MiB). Of course, if
the encoding data itself gets corrupted or we lose more than two of the blocks
covered by any single code, we cannot recover anymore.

While making error correction feasible for block-based storage, interleaving
does have the side effect of making decoding slower, because instead of reading
a single block, we need to read multiple blocks spread across the partition to
recover from an error. Fortunately, this is not a huge issue when combined with
dm-verity and solid-state storage as we only need to resort to decoding if a
block is actually corrupted, which still is rather rare, and random access reads
are relatively fast even if we have to correct errors.

Conclusion

Strictly enforced verified boot improves security, but can also reduce
reliability by increasing the impact of disk corruption that may occur on
devices due to software bugs or hardware issues.

The new error correction feature we developed for dm-verity makes it possible
for devices to recover from the loss of up to 16-24 MiB of consecutive blocks
anywhere on a typical 2-3 GiB system partition with only 0.8% space overhead and
no performance impact unless corruption is detected. This improves the security
and reliability of devices running Android 7.0.

Changes to Trusted Certificate Authorities in Android Nougat

Posted by Chad Brubaker, Android Security team

In Android Nougat, we�ve changed how Android handles trusted certificate
authorities (CAs) to provide safer defaults for secure app traffic. Most apps
and users should not be affected by these changes or need to take any action.
The changes include:

• Safe and easy APIs to trust custom CAs.
  
• Apps that target API Level 24 and above no longer trust user or admin-added
  CAs for secure connections, by default.
  
• All devices running Android Nougat offer the same standardized set of system
  CAs�no device-specific customizations.

For more details on these changes and what to do if you�re affected by them,
read on.

Safe and easy APIs

Apps have always been able customize which certificate authorities they trust.
However, we saw apps making mistakes due to the complexities of the Java TLS
APIs. To address this we href="https://developer.android.com/preview/features/security-config.html">improved
the APIs for customizing trust.

User-added CAs

Protection of all application data is a key goal of the Android application
sandbox. Android Nougat changes how applications interact with user- and
admin-supplied CAs. By default, apps that target API level 24 will�by design�not
honor such CAs unless the app explicitly opts in. This safe-by-default setting
reduces application attack surface and encourages consistent handling of network
and file-based application data.

Customizing trusted CAs

Customizing the CAs your app trusts on Android Nougat is easy using the Network
Security Config. Trust can be specified across the whole app or only for
connections to certain domains, as needed. Below are some examples for trusting
a custom or user-added CA, in addition to the system CAs. For more examples and
details, see href="https://developer.android.com/preview/features/security-config.html">the
full documentation.

Trusting custom CAs for debugging

To allow your app to trust custom CAs only for local debugging, include
something like this in your Network Security Config. The CAs will only be
trusted while your app is marked as debuggable.

<network-security-config>  
      <debug-overrides>  
           <trust-anchors>  
                <!-- Trust user added CAs while debuggable only -->
                <certificates src="user" />  
           </trust-anchors>  
      </domain-config>  
 </network-security-config>

Trusting custom CAs for a domain

To allow your app to trust custom CAs for a specific domain, include something
like this in your Network Security Config.

<network-security-config>  
      <domain-config>  
           <domain includeSubdomains="true">internal.example.com</domain>  
           <trust-anchors>  
                <!-- Only trust the CAs included with the app  
                     for connections to internal.example.com -->  
                <certificates src="@raw/cas" />  
           </trust-anchors>  
      </domain-config>  
 </network-security-config>

Trusting user-added CAs for some domains

To allow your app to trust user-added CAs for multiple domains, include
something like this in your Network Security Config.

<network-security-config>  
      <domain-config>  
           <domain includeSubdomains="true">userCaDomain.com</domain>  
           <domain includeSubdomains="true">otherUserCaDomain.com</domain>  
           <trust-anchors>  
                  <!-- Trust preinstalled CAs -->  
                  <certificates src="system" />  
                  <!-- Additionally trust user added CAs -->  
                  <certificates src="user" />  
           </trust-anchors>  
      </domain-config>  
 </network-security-config>

Trusting user-added CAs for all domains except some

To allow your app to trust user-added CAs for all domains, except for those
specified, include something like this in your Network Security Config.

<network-security-config>  
      <base-config>  
           <trust-anchors>  
                <!-- Trust preinstalled CAs -->  
                <certificates src="system" />  
                <!-- Additionally trust user added CAs -->  
                <certificates src="user" />  
           </trust-anchors>  
      </base-config>  
      <domain-config>  
           <domain includeSubdomains="true">sensitive.example.com</domain>  
           <trust-anchors>  
                <!-- Only allow sensitive content to be exchanged  
             with the real server and not any user or  
    admin configured MiTMs -->  
                <certificates src="system" />  
           <trust-anchors>  
      </domain-config>  
 </network-security-config>

Trusting user-added CAs for all secure connections

To allow your app to trust user-added CAs for all secure connections, add this
in your Network Security Config.

<network-security-config>  
      <base-config>  
            <trust-anchors>  
                <!-- Trust preinstalled CAs -->  
                <certificates src="system" />  
                <!-- Additionally trust user added CAs -->  
                <certificates src="user" />  
           </trust-anchors>  
      </base-config>  
 </network-security-config>

Standardized set of system-trusted CAs

To provide a more consistent and more secure experience across the Android
ecosystem, beginning with Android Nougat, compatible devices trust only the
standardized system CAs maintained in href="https://android.googlesource.com/platform/system/ca-certificates/">AOSP.

Previously, the set of preinstalled CAs bundled with the system could vary from
device to device. This could lead to compatibility issues when some devices did
not include CAs that apps needed for connections as well as potential security
issues if CAs that did not meet our security requirements were included on some
devices.

What if I have a CA I believe should be included on Android?

First, be sure that your CA needs to be included in the system. The preinstalled
CAs are only for CAs that meet our security requirements
because they affect the secure connections of most apps on the device. If you
need to add a CA for connecting to hosts that use that CA, you should instead
customize your apps and services that connect to those hosts. For more
information, see the Customizing trusted CAs section above.

If you operate a CA that you believe should be included in Android, first
complete the Mozilla CA
Inclusion Process and then file a href="https://code.google.com/p/android/issues/entry">feature request
against Android to have the CA added to the standardized set of system CAs.

One Year of Android Security Rewards

Posted by Quan To, Program Manager, Android Security



A year ago, we added Android Security Rewards to the long standing Google Vulnerability Rewards Program. We offered up to $38,000 per report that we used to fix vulnerabilities and protect Android users.



Since then, we have received over 250 qualifying vulnerability reports from researchers that have helped make Android and mobile security stronger. More than a third of them were reported in Media Server which has been hardened in Android N to make it more resistant to vulnerabilities.



While the program is focused on Nexus devices and has a primary goal of improving Android security, more than a quarter of the issues were reported in code that is developed and used outside of the Android Open Source Project. Fixing these kernel and device driver bugs helps improve security of the broader mobile industry (and even some non-mobile platforms).



By the Numbers



Here�s a quick rundown of the Android VRP�s first year:

• We paid over $550,000 to 82 individuals. That�s an average of $2,200 per reward and $6,700 per researcher.


• We paid our top researcher, @heisecode, $75,750 for 26 vulnerability reports.


• We paid 15 researchers $10,000 or more.


• There were no payouts for the top reward for a complete remote exploit chain leading to TrustZone or Verified Boot compromise.

Thank you to those who submitted high quality vulnerability reports to us last year.

Improvements to Android VRP

We�re constantly working to improve the program and today we�re making a few changes to all vulnerability reports filed after June 1, 2016.

We�re paying more!

• We will now pay 33% more for a high-quality vulnerability report with proof of concept. For example, the reward for a Critical vulnerability report with a proof of concept increased from $3000 to $4000.


• A high quality vulnerability report with a proof of concept, a CTS Test, or a patch will receive an additional 50% more.


• We�re raising our rewards for a remote or proximal kernel exploit from $20,000 to $30,000.


• A remote exploit chain or exploits leading to TrustZone or Verified Boot compromise increase from $30,000 to $50,000.

All of the changes, as well as the additional terms of the program, are explained in more detail in our Program Rules. If you�re interested in helping us find security vulnerabilities, take a look at Bug Hunter University and learn how to submit high quality vulnerability reports. Remember, the better the report, the more you�ll get paid. We also recently updated our severity ratings, so make sure to check those out, too.

Thank you to everyone who helped us make Android safer. Together, we made a huge investment in security research that has made Android stronger. We�re just getting started and are looking forward to doing even more in the future.

Security "Crypto" provider deprecated in Android N

Posted by Sergio Giro, software engineer

If your Android app derives keys using the SHA1PRNG algorithm from the Crypto
provider, you must start using a real key derivation function and possibly re-encrypt your data.

The Java Cryptography Architecture allows developers to create an instance of a class like a cipher, or a pseudo-random number generator, using calls like:


SomeClass.getInstance("SomeAlgorithm", "SomeProvider");


Or simply:


SomeClass.getInstance("SomeAlgorithm");


For instance,


Cipher.getInstance(�AES/CBC/PKCS5PADDING�);


SecureRandom.getInstance(�SHA1PRNG�);


On Android, we don�t recommend specifying the provider. In general, any call to
the Java Cryptography Extension (JCE) APIs specifying a provider should only be
done if the provider is included in the application or if the application is
able to deal with a possible ProviderNotFoundException.

Unfortunately, many apps depend on the now removed �Crypto� provider for an
anti-pattern of key derivation.

This provider only provided an implementation of the algorithm �SHA1PRNG� for
instances of SecureRandom. The problem is that the SHA1PRNG algorithm is not
cryptographically strong. For readers interested in the details, On
statistical distance based testing of pseudo random sequences and experiments
with PHP and Debian OpenSSL,Section 8.1, by Yongge Want and Tony Nicol,
states that the �random� sequence, considered in binary form, is biased towards
returning 0s, and that the bias worsens depending on the seed.

As a result, in Android N we are deprecating the
implementation of the SHA1PRNG algorithm and the Crypto provider altogether.
We�d previously covered the issues with using SecureRandom for key derivation a
few years ago in href=http://android-developers.blogspot.com/2013/02/using-cryptography-to-store-credentials.html>Using
Cryptography to Store Credentials Safely. However, given its continued use,
we will revisit it here.

A common but incorrect usage of this provider was to derive keys for encryption
by using a password as a seed. The implementation of SHA1PRNG had a bug that
made it deterministic if setSeed() was called before obtaining output. This bug
was used to derive a key by supplying a password as a seed, and then using the
"random" output bytes for the key (where �random� in this sentence means
�predictable and cryptographically weak�). Such a key could then be used to
encrypt and decrypt data.

In the following, we explain how to derive keys correctly, and how to decrypt
data that has been encrypted using an insecure key. There�s also a
full example, including a helper class to use the deprecated SHA1PRNG
functionality, with the sole purpose of decrypting data that would be otherwise
unavailable.

Keys can be derived in the following way:

• If you're reading an AES key from disk, just store the actual key and don't go through this weird dance. You can get a SecretKey for AES usage from the bytes by doing:
  

  
  SecretKey key = new SecretKeySpec(keyBytes, "AES");
  



• If you're using a password to derive a key, follow href="http://nelenkov.blogspot.com/2012/04/using-password-based-encryption-on.html">Nikolay Elenkov's excellent tutorial with the caveat that a good rule of thumb is the salt size should be the same size as the key output. It looks like this:

   /* User types in their password: */  
   String password = "password";  

   /* Store these things on disk used to derive key later: */  
   int iterationCount = 1000;  
   int saltLength = 32; // bytes; should be the same size
              as the output (256 / 8 = 32)  
   int keyLength = 256; // 256-bits for AES-256, 128-bits for AES-128, etc  
   byte[] salt; // Should be of saltLength  

   /* When first creating the key, obtain a salt with this: */  
   SecureRandom random = new SecureRandom();  
   byte[] salt = new byte[saltLength];  
   random.nextBytes(salt);  

   /* Use this to derive the key from the password: */  
   KeySpec keySpec = new PBEKeySpec(password.toCharArray(), salt,  
              iterationCount, keyLength);  
   SecretKeyFactory keyFactory = SecretKeyFactory  
              .getInstance("PBKDF2WithHmacSHA1");  
   byte[] keyBytes = keyFactory.generateSecret(keySpec).getEncoded();  
   SecretKey key = new SecretKeySpec(keyBytes, "AES");  

That's it. You should not need anything else.

To make transitioning data easier, we covered the case of developers that have
data encrypted with an insecure key, which is derived from a password every
time. You can use the helper class InsecureSHA1PRNGKeyDerivator in
the example app to derive the key.

 private static SecretKey deriveKeyInsecurely(String password, int
 keySizeInBytes) {  
    byte[] passwordBytes = password.getBytes(StandardCharsets.US_ASCII);  
    return new SecretKeySpec(  
            InsecureSHA1PRNGKeyDerivator.deriveInsecureKey(  
                     passwordBytes, keySizeInBytes),  
            "AES");  
 }  

You can then re-encrypt your data with a securely derived key as explained
above, and live a happy life ever after.

Note 1: as a temporary measure to keep apps working, we decided to still create
the instance for apps targeting SDK version 23, the SDK version for Marshmallow,
or less. Please don't rely on the presence of the Crypto provider in the Android
SDK, our plan is to delete it completely in the future.

Note 2: Because many parts of the system assume the existence of a SHA1PRNG
algorithm, when an instance of SHA1PRNG is requested and the provider is not
specified we return an instance of OpenSSLRandom, which is a strong source of
random numbers derived from OpenSSL.