| <html devsite> |
| <head> |
| <title>Security Updates and Resources</title> |
| <meta name="project_path" value="/_project.yaml" /> |
| <meta name="book_path" value="/_book.yaml" /> |
| </head> |
| <body> |
| <!-- |
| Copyright 2017 The Android Open Source Project |
| |
| Licensed under the Apache License, Version 2.0 (the "License"); |
| you may not use this file except in compliance with the License. |
| You may obtain a copy of the License at |
| |
| http://www.apache.org/licenses/LICENSE-2.0 |
| |
| Unless required by applicable law or agreed to in writing, software |
| distributed under the License is distributed on an "AS IS" BASIS, |
| WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. |
| See the License for the specific language governing permissions and |
| limitations under the License. |
| --> |
| |
| |
| |
| <h2 id=android_security_bug_lifecycle>Android security bug lifecycle</h2> |
| |
| <p>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.</p> |
| |
| <p>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 <a |
| href="https://issuetracker.google.com/issues/new?component=190951">Android |
| Security Issue template</a>, 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.</p> |
| |
| <h2 id=report-issues>Reporting security issues</h2> |
| |
| <p>Any developer, Android user, or security researcher can notify the Android |
| security team of potential security issues through the <a |
| href="https://issuetracker.google.com/issues/new?component=190951"> |
| Android Security Issue template</a>.</p> |
| |
| <p>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.</p> |
| |
| <h2 id=triaging_bugs>Triaging bugs</h2> |
| |
| <p>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.</p> |
| |
| <h3 id=process_types>Process types</h3> |
| <p>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.</p> |
| <table> |
| <tr> |
| <th>Process type</th> |
| <th>Type definition</th> |
| </tr> |
| <tr> |
| <td>Constrained process</td> |
| <td>A process that runs in a highly limited SELinux domain.<br /> |
| OR<br /> |
| A process that is significantly more limited than a normal application.</td> |
| </tr> |
| <tr> |
| <td>Unprivileged process</td> |
| <td>A third-party application or process.<br /> |
| OR<br /> |
| An application or process that runs in the SELinux <code>untrusted_app</code> domain.</td> |
| </tr> |
| <tr> |
| <td>Privileged process</td> |
| <td>An application or process with capabilities that are restricted by SELinux |
| <code>untrusted_app</code> domain.<br /> |
| OR<br /> |
| An application or process with important privileges that a third-party |
| application cannot obtain.</td> |
| </tr> |
| <tr> |
| <td>Kernel</td> |
| <td>Functionality that is either part of the kernel or runs in the same CPU context |
| as the kernel (like device drivers).</td> |
| </tr> |
| <tr> |
| <td>Trusted Execution Environment (TEE)</td> |
| <td> A component that is designed to be protected from even a hostile kernel.</td> |
| </tr> |
| </table> |
| |
| |
| <h3 id=severity>Severity</h3> |
| |
| |
| <p>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:</p> |
| <table> |
| <tr> |
| <th>Rating</th> |
| <th>Consequence of successful exploitation</th> |
| </tr> |
| <tr> |
| <td><strong>Critical</strong></td> |
| <td> |
| <ul> |
| <li> Remote arbitrary code execution in a privileged process |
| <li> Permanent device compromise (device cannot be repaired without re-flashing the |
| entire operating system) |
| <li> Unauthorized access to data secured by the TEE |
| <li> Remote permanent denial of service (device inoperability: completely permanent |
| or requiring re-flashing the entire operating system) |
| </ul> |
| </td> |
| </tr> |
| <tr> |
| <td><strong>High</strong></td> |
| <td> |
| <ul> |
| <li> Remote arbitrary code execution in an unprivileged process |
| <li> Remote access to protected data (data normally accessible only to locally |
| installed apps that request permission, or that is limited to a privileged |
| process) |
| <li> Remote bypass of user interaction requirements (access to functionality that |
| would normally require either user initiation or user permission) |
| <li> Local arbitrary code execution in a privileged process |
| <li> Local permanent denial of service (device inoperability: completely permanent |
| or requiring re-flashing the entire operating system) |
| <li> A general bypass for a kernel level defense in depth or exploit mitigation |
| technology |
| <li> Remote temporary device denial of service (remote hang or reboot) |
| <li> Local bypass of user interaction requirements for any developer or security |
| settings modifications |
| <li> A general bypass for operating system protections that isolate application data |
| from other applications |
| <li> Lockscreen bypass |
| </ul> |
| </td> |
| </tr> |
| <tr> |
| <td><strong>Moderate</strong></td> |
| <td> |
| <ul> |
| <li> Remote arbitrary code execution in a constrained process |
| <li> Local bypass of user interaction requirements (access to functionality that |
| would normally require either user initiation or user permission) |
| <li> Local temporary denial of service (device requires a factory reset) |
| <li> A general bypass for a user level defense in depth or exploit mitigation |
| technology in a privileged process |
| <li> Remote access to unprotected data (data normally accessible to any locally |
| installed app) |
| <li> Bypass of Device Protection/ Factory Reset Protection |
| </ul> |
| </td> |
| </tr> |
| <tr> |
| <td><strong>Low</strong></td> |
| <td> |
| <ul> |
| <li> A general bypass for a user level defense in depth or exploit mitigation |
| technology in an unprivileged process |
| <li> 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) |
| </ul> |
| </td> |
| </tr> |
| </table> |
| |
| |
| <h4 id=local_vs_remote>Local vs. remote</h4> |
| |
| <p>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.</p> |
| |
| <p>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.</p> |
| |
| <h3 id=rating_modifiers>Rating modifiers</h3> |
| <p>While the severity of security vulnerabilities is often easy to identify, |
| ratings may change based on circumstances. </p> |
| <table> |
| <tr> |
| <th>Reason</th> |
| <th>Effect</th> |
| </tr> |
| <tr> |
| <td>Requires running as a privileged process to execute the attack</td> |
| <td>-1 Severity</td> |
| </tr> |
| <tr> |
| <td>Vulnerability-specific details limit the impact of the issue </td> |
| <td>-1 Severity</td> |
| </tr> |
| </table> |
| |
| |
| <h3 id=affected_component>Affected component</h3> |
| |
| <p>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.</p> |
| |
| <p>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.</p> |
| |
| <p>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. </p> |
| |
| <h2 id=notifying_partners>Notifying partners</h2> |
| |
| <p>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.</p> |
| |
| <h2 id=releasing_code_to_aosp>Releasing code to AOSP</h2> |
| |
| <p>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.</p> |
| |
| <h2 id=android_updates>Receiving Android updates</h2> |
| |
| <p>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 <a |
| href="https://developers.google.com/android/nexus/images">Nexus factory |
| images</a> that can be side-loaded to devices.</p> |
| |
| <h2 id=updating_google_services>Updating Google services</h2> |
| |
| <p>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 |
| <a href="https://support.google.com/accounts/answer/2812853">Verify Apps</a> |
| feature to warn users about applications that may be potentially harmful.</p> |
| |
| <h2 id=other_resources>Other resources</h2> |
| |
| <p>Information for Android application developers: <a |
| href="https://developer.android.com">https://developer.android.com</a></p> |
| |
| <p>Security information exists throughout the Android Open Source and Developer |
| sites. Good places to start:<br> |
| <a href="https://source.android.com/security/index.html">https://source.android.com/security/index.html</a><br> |
| <a href="https://developer.android.com/training/articles/security-tips.html">https://developer.android.com/training/articles/security-tips.html</a></p> |
| |
| <h3 id=reports>Reports</h3> |
| <p>Sometimes the Android Security team publishes reports or whitepapers. Here are some of the most recent.</p> |
| <ul> |
| <li><a href="http://static.googleusercontent.com/media/source.android.com/en//security/reports/Google_Android_Security_2016_Report_Final.pdf"> |
| Android Security 2016 Year In Review</a></li> |
| <li><a href="http://static.googleusercontent.com/media/source.android.com/en//security/reports/Google_Android_Security_2015_Report_Final.pdf"> |
| Android Security 2015 Year In Review</a></li> |
| <li><a href="http://static.googleusercontent.com/media/source.android.com/en//security/reports/Google_Android_Security_2014_Report_Final.pdf"> |
| Android Security 2014 Year In Review</a></li> |
| <li><a href="http://static.googleusercontent.com/media/source.android.com/en//security/reports/Android_WhitePaper_Final_02092016.pdf"> |
| Android Security white paper</a></li> |
| <li><a href="http://static.googleusercontent.com/media/source.android.com/en//security/reports/Google_Android_Security_PHA_classifications.pdf"> |
| Classifications for Potentially Harmful Applications</a></li> |
| </ul> |
| |
| <h3 id=slides>Android Bootcamp 2016 slides</h3> |
| <p>The Android Security team has published their Android Bootcamp 2016 slides that cover new security features.</p> |
| <ul> |
| <li><a href="http://static.googleusercontent.com/media/source.android.com/en//security/reports/Android-Bootcamp-2016-Verified-Boot-and-Encryption.pdf"> |
| Verified boot and encryption</a></li> |
| <li><a href="http://static.googleusercontent.com/media/source.android.com/en//security/reports/Android-Bootcamp-2016-SafetyNet.pdf"> |
| SafetyNet</a></li> |
| <li><a href="http://static.googleusercontent.com/media/source.android.com/en//security/reports/Android-Bootcamp-2016-New-App-Lifecycle-for-Encryption.pdf"> |
| New app life cycle for encryption</a></li> |
| <li><a href="http://static.googleusercontent.com/media/source.android.com/en//security/reports/Android-Bootcamp-2016-Keeping-Google-Play-safe.pdf"> |
| Keeping Google Play safe</a></li> |
| <li><a href="http://static.googleusercontent.com/media/source.android.com/en//security/reports/Android-Bootcamp-2016-Defense-in-depth-efforts.pdf"> |
| Defense in depth efforts</a></li> |
| <li><a href="http://static.googleusercontent.com/media/source.android.com/en//security/reports/Android-Bootcamp-2016-Android-Keystore-Attestation.pdf"> |
| Keystore attestation</a></li> |
| <li><a href="http://static.googleusercontent.com/media/source.android.com/en//security/reports/Android-Bootcamp-2016-Android-Attack-Team.pdf"> |
| Android attack team</a></li> |
| </ul> |
| |
| |
| </body> |
| </html> |