The Wayback Machine - https://web.archive.org/web/20170112142654/https://source.android.com/security/overview/updates-resources.html

Security updates and resources

In this document

    Android security bug lifecycle

    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 Open Source Project (AOSP) Security bug report 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 AOSP bug tracker Security bug report template.

    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 are restricted by SELinux untrusted_app domain.
    OR
    An application or process with important privileges that a third-party application cannot obtain.
    Kernel Functionality that is either part of the kernel or runs in the same CPU context as the kernel (like device drivers).
    Trusted Execution Environment (TEE) A component that is designed to be protected from even a hostile kernel.

    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
    • Remote arbitrary code execution in a privileged process
    • Permanent device compromise (device cannot be repaired without re-flashing the entire operating system)
    • Unauthorized access to data secured by the TEE
    • Remote permanent denial of service (device inoperability: completely permanent or requiring re-flashing the entire operating system)
    High
    • Remote arbitrary code execution in an unprivileged process
    • Remote access to protected data (data normally accessible only to locally installed apps that request permission, or that is limited to a privileged process)
    • Remote bypass of user interaction requirements (access to functionality that would normally require either user initiation or user permission)
    • Local arbitrary code execution in a privileged process
    • Local permanent denial of service (device inoperability: completely permanent or requiring re-flashing the entire operating system)
    • A general bypass for a kernel level defense in depth or exploit mitigation technology
    • Remote temporary device denial of service (remote hang or reboot)
    • Local bypass of user interaction requirements for any developer or security settings modifications
    • A general bypass for operating system protections that isolate application data from other applications
    • Lockscreen bypass
    Moderate
    • Remote arbitrary code execution in a constrained process
    • Local bypass of user interaction requirements (access to functionality that would normally require either user initiation or user permission)
    • Local temporary denial of service (device requires a factory reset)
    • A general bypass for a user level defense in depth or exploit mitigation technology in a privileged process
    • Remote access to unprotected data (data normally accessible to any locally installed app)
    • Bypass of Device Protection/ Factory Reset Protection
    Low
    • A general bypass for a user level defense in depth or exploit mitigation technology in an unprivileged process
    • Local temporary denial of service (can be resolved by booting the device into Safe Mode and removing the problematic application, or by a factory reset if the device does not support Safe Mode)

    Local vs. remote

    A remote attack vector indicates the bug could be exploited without installing an app or without physical access to the device. This includes bugs that could 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.

    Local attacks require the victim to install an 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. The Android security team also considers NFC-based attacks as local.

    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

    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 (e.g., 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 moderate or higher severity security vulnerability in AOSP is fixed, we'll notify Android partners of issue details and provide patches for a minimum of the most recent three Android releases. The Android security team currently provides patches for Android versions 4.4 (KitKat), 5.0 (Lollipop), 5.1 (Lollipop MR1), and 6.0 (Marshmallow). This list of backport-supported versions changes with each new Android release.

    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 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.

    Android Bootcamp 2016 slides

    The Android Security team has published their Android Bootcamp 2016 slides that cover new security features.