Security Updates and Resources

The Android security team is responsible for managing security vulnerabilities discovered in the Android platform and many of the core Android apps bundled with Android devices.

The Android security team finds security vulnerabilities through internal research and also responds to bugs reported by third parties. Sources of external bugs include issues reported through the Android Security Issue template, published and pre-published academic research, upstream open source project maintainers, notifications from our device manufacturer partners, and publicly disclosed issues posted on blogs or social media.

Reporting security issues

Any developer, Android user, or security researcher can notify the Android security team of potential security issues through the security vulnerability reporting form.

Bugs marked as security issues are not externally visible, but they may eventually be made visible after the issue is evaluated or resolved. If you plan to submit a patch or Compatibility Test Suite (CTS) test to resolve a security issue, please attach it to the bug report and wait for a response before uploading the code to AOSP.

Triaging bugs

The first task in handling a security vulnerability is to identify the severity of the bug and which component of Android is affected. The severity determines how the issue is prioritized, and the component determines who fixes the bug, who is notified, and how the fix gets deployed to users.

Process types

This table covers the definitions of process types. The process type can be defined by the type of application or process or the area in which it runs. This table is ordered from least to most privileged.

Process type	Type definition
Constrained process	A process that runs in a highly limited SELinux domain. OR A process that is significantly more limited than a normal application.
Unprivileged process	A third-party application or process. OR An application or process that runs in the SELinux `untrusted_app` domain.
Privileged process	An application or process with capabilities that would be forbidden by the SELinux `untrusted_app` domain. OR An application or process with important privileges that a third-party application cannot obtain. OR A built-in hardware component on the device that is not part of the Trusted Computing Base (TCB).
Trusted Computing Base (TCB)	Functionality that is part of the kernel, runs in the same CPU context as the kernel (such as device drivers), has direct access to kernel memory (such as hardware components on the device), has the capability to load scripts into a kernel component (for example, eBPF), the Baseband Processor, or is one of a handful of user services that is considered kernel equivalent: `init`, `ueventd`, and `vold`.
Bootloader	A component that configures the device on boot and then passes control to the Android OS.
Trusted Execution Environment (TEE)	A component that is designed to be protected from even a hostile kernel.
Secure element (SE)	An optional component designed to be protected from all other components on the device and from physical attack, as defined at Introduction to Secure Elements

Severity

The severity of a bug generally reflects the potential harm that could occur if a bug was successfully exploited. Use the following criteria to determine the severity:

Rating	Consequence of successful exploitation
Critical	Unauthorized access to data secured by the SE Arbitrary code execution in the TEE or SE Remote arbitrary code execution in a privileged process, Bootloader, or the TCB Remote permanent denial of service (device inoperability: completely permanent or requiring re-flashing the entire operating system or a factory reset) Remote bypass of user interaction requirements on package installation or equivalent behavior Remote bypass of user interaction requirements for any developer, security, or privacy settings Remote Secure Boot bypass Bypass of safety mechanisms designed to prevent critical hardware components from malfunctioning (for example, thermal protections)
High	Local Secure Boot bypass A complete bypass of a core security feature (such as SELinux, FDE, or seccomp) Remote arbitrary code execution in an unprivileged process Local arbitrary code execution in a privileged process, Bootloader, or the TCB Unauthorized access to data secured by the TEE Attacks against an SE that result in downgrading to a less secure implementation Local bypass of user interaction requirements on package installation or equivalent behavior Remote access to protected data (data that is limited to a privileged process) Local permanent denial of service (device inoperability: permanent or requiring re-flashing the entire operating system or factory reset) Remote bypass of user interaction requirements (access to functionality or data that would normally require either user initiation or user permission) Transmitting sensitive information over an insecure network protocol (for example, HTTP and unencrypted Bluetooth) when the requester expects a secure transmission. Note that this doesn't apply to Wi-Fi encryption (such as WEP). A general bypass for a defense in depth or exploit mitigation technology in the Bootloader or TEE A general bypass for operating system protections that isolate application data or user profiles from each other Local bypass of user interaction requirements for any developer, security, or privacy settings Cryptographic Vulnerability in Standard TLS that allows for man-in-the-middle attacks Lockscreen bypass Bypass of Device Protection/ Factory Reset Protection / Carrier Restrictions Targeted prevention of access to emergency services Bypass of user interaction requirements that are secured by the TEE
Moderate	Remote arbitrary code execution in a constrained process Remote temporary device denial of service (remote hang or reboot) Local arbitrary code execution in an unprivileged process A general bypass for a defense in depth or exploit mitigation technology in a privileged process or the TCB Bypass of restrictions on a constrained process Remote access to unprotected data (data normally accessible to any locally installed app) Local access to protected data (data that is limited to a privileged process) Local bypass of user interaction requirements (access to functionality that would normally require either user initiation or user permission) Cryptographic Vulnerability in standard crypto primitives that allows leaking of plaintext (not primitives used in TLS) Bypassing WiFi encryption or authentication in a way that allows an attacker to connect to either the Android device when acting as a hotspot or to the network access point (AP) that the device is connected to
Low	Local arbitrary code execution in a constrained process Cryptographic Vulnerability in non-standard usage A general bypass for a user level defense in depth or exploit mitigation technology in an unprivileged process
No Security Impact (NSI)	A vulnerability whose impact has been mitigated by one or more rating modifiers or version-specific architecture changes such that the effective severity is below Low, although the underlying code issue may remain

Rating modifiers

While the severity of security vulnerabilities is often easy to identify, ratings may change based on circumstances.

Reason	Effect
Requires running as a privileged process to execute the attack	-1 Severity
Vulnerability-specific details limit the impact of the issue	-1 Severity
Compiler or platform configurations mitigate a vulnerability in the source code	Moderate Severity if the underlying vulnerability is Moderate or higher
Requires physical access to device internals and is still possible if the phone is off or hasn't been unlocked since being powered on	-1 Severity
Requires physical access to device internals while the phone is on and has previously been unlocked	-2 Severity
A local attack that requires the bootloader to be unlocked	No higher than Low
A local attack that requires Developer Mode or any persistent developer mode settings to be enabled on the device (and isn't a bug in Developer Mode).	No higher than Low
If no SELinux domain can conduct the operation under the Google-provided SEPolicy	No Security Impact

Local vs. remote

A remote attack vector indicates the bug can be exploited without installing an app or without physical access to a device. This includes bugs that can be triggered by browsing to a web page, reading an email, receiving an SMS message, or connecting to a hostile network. For the purpose of our severity ratings, the Android security team also considers "proximal" attack vectors as remote. These include bugs that can be exploited only by an attacker who is physically near the target device, for example, a bug that requires sending malformed Wi-Fi or Bluetooth packets. The Android security team considers NFC-based attacks as proximal and therefore remote.

Local attacks require the victim to run an app, either by installing and running an app or by consenting to run an Instant App. For the purpose of severity ratings, the Android security team also considers physical attack vectors as local. These include bugs that can be exploited only by an attacker who has physical access to the device, for example a bug in a lock screen or one that requires plugging in a USB cable. Note that attacks that require a USB connection are the same severity regardless of whether the device is required to be unlocked or not; it's common for devices to be unlocked while plugged into USB.

Wi-Fi security

Android assumes that all networks are hostile and could be injecting attacks or spying on traffic. To ensure that network-level adversaries don't bypass app data protections, Android strongly encourages that all network traffic use end-to-end encryption. Link-level encryption is insufficient.

Affected component

The development team responsible for fixing the bug depends on which component the bug is in. It could be a core component of the Android platform, a kernel driver supplied by an original equipment manufacturer (OEM), or one of the pre-loaded apps on Nexus devices.

Bugs in AOSP code are fixed by the Android engineering team. Low-severity bugs, bugs in certain components, or bugs that are already publicly known may be fixed directly in the publicly available AOSP master branch; otherwise they're fixed in our internal repositories first.

The component is also a factor in how users get updates. A bug in the framework or kernel will require an over-the-air (OTA) firmware update that each OEM will need to push. A bug in an app or library published in Google Play (for example, Gmail, Google Play Services, WebView in Lollipop and later versions) can be sent to Android users as an update from Google Play.

Notifying partners

When a security vulnerability in AOSP is fixed in an Android Security Bulletin, we'll notify Android partners of issue details and provide patches. The list of backport-supported versions changes with each new Android release. Contact your device manufacturer for the list of supported devices.

Releasing code to AOSP

If the security bug is in an AOSP component, the fix will be pushed out to AOSP after the OTA is released to users. Fixes for low-severity issues may be submitted directly to the AOSP master branch before a fix is available.

Receiving Android updates

Updates to the Android system are generally delivered to devices through OTA update packages. These updates may come from the OEM who produced the device or the carrier who provides service to the device. Google Nexus device updates come from the Google Nexus team after going through a carrier technical acceptance (TA) testing procedure. Google also publishes Nexus and Pixel factory images that can be side-loaded to devices.

Updating Google services

In addition to providing patches for security bugs, the Android security team also review security bugs to determine if there are other ways to protect users. For example, Google Play scans all applications and will remove any application that attempts to exploit a security bug. For applications installed from outside of Google Play, devices with Google Play Services may also use the Verify Apps feature to warn users about applications that may be potentially harmful.

Other resources

Information for Android application developers: https://developer.android.com

Security information exists throughout the Android Open Source and Developer sites. Good places to start:
https://source.android.com/security/index.html
https://developer.android.com/training/articles/security-tips.html

Reports

Sometimes the Android Security team publishes reports or whitepapers. Here are some of the most recent.

Presentations

The Android Security team presents at various conferences and talks. Here are some of their slides: