1page.title= Security updates and resources 2@jd:body 3 4<!-- 5 Copyright 2015 The Android Open Source Project 6 7 Licensed under the Apache License, Version 2.0 (the "License"); 8 you may not use this file except in compliance with the License. 9 You may obtain a copy of the License at 10 11 http://www.apache.org/licenses/LICENSE-2.0 12 13 Unless required by applicable law or agreed to in writing, software 14 distributed under the License is distributed on an "AS IS" BASIS, 15 WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 16 See the License for the specific language governing permissions and 17 limitations under the License. 18--> 19<div id="qv-wrapper"> 20 <div id="qv"> 21 <h2>In this document</h2> 22 <ol id="auto-toc"></ol> 23 </div> 24</div> 25 26<h2 id=android_security_bug_lifecycle>Android security bug lifecycle</h2> 27 28<p>The Android security team is responsible for managing security vulnerabilities 29discovered in the Android platform and many of the core Android apps bundled 30with Android devices.</p> 31 32<p>The Android security team finds security vulnerabilities through internal 33research and also responds to bugs reported by third parties. Sources of 34external bugs include issues reported through the Android Open Source 35Project (AOSP) <a 36href="https://code.google.com/p/android/issues/entry?template=Security%20bug%20report">Security 37bug report</a> template, published and pre-published academic research, 38upstream open source project maintainers, notifications from our device 39manufacturer partners, and publicly disclosed issues posted on blogs or social 40media.</p> 41 42<h2 id=report-issues>Reporting security issues</h2> 43 44<p>Any developer, Android user, or security researcher can notify the Android 45security team of potential security issues through the AOSP bug tracker <a 46href="https://code.google.com/p/android/issues/entry?template=Security%20bug%20report">Security 47bug report</a> template.</p> 48 49<p>Bugs marked as security issues are not externally visible, but they may 50eventually be made visible after the issue is evaluated or resolved. If you 51plan to submit a patch or Compatibility Test Suite (CTS) test to resolve a 52security issue, please attach it to the bug report and wait for a response 53before uploading the code to AOSP.</p> 54 55<h2 id=triaging_bugs>Triaging bugs</h2> 56 57<p>The first task in handling a security vulnerability is to identify the severity 58of the bug and which component of Android is affected. The severity determines 59how the issue is prioritized, and the component determines who fixes the bug, 60who is notified, and how the fix gets deployed to users.</p> 61 62<h3 id=severity>Severity</h3> 63 64<p>The severity of a bug generally reflects the potential harm that could occur if 65a bug was successfully exploited. Use the following criteria to determine the 66severity:</p> 67<p class="table-caption" id="severity-criteria"> 68 <strong>Table 1.</strong> Severity ratings and associated consequences</p> 69<table> 70 <tr> 71 <th>Rating</th> 72 <th>Consequence of successful exploitation</th> 73 </tr> 74 <tr> 75 <td><strong>Critical</strong></td> 76 <td> 77<ul> 78<li>Remote privileged code execution (execution at a privilege level that 79third-party apps cannot obtain) 80<li>Local permanent device compromise (device cannot be repaired without 81re-flashing the entire operating system, such as a verified boot or Trusted 82Execution Environment/TEE compromise) 83<li>Remote permanent denial of service (inoperability, either completely permanent 84or requiring re-flashing the device) 85</ul> 86</td> 87 </tr> 88 <tr> 89 <td><strong>High</strong></td> 90 <td> 91<ul> 92<li>Remote unprivileged code execution (execution at a privilege level that 93third-party apps can obtain through installation) 94<li>Local access to system/signature-level permission data or capabilities without 95permission 96<li>Local permanent denial-of-service (inoperability, either completely permanent 97or requiring re-flashing the device) 98<li>Remote temporary denial-of-service (remote hang or reboot) 99</ul> 100</td> 101 </tr> 102 <tr> 103 <td><strong>Moderate</strong></td> 104 <td> 105<ul> 106<li>Access to "<a 107href="http://developer.android.com/guide/topics/manifest/permission-element.html#plevel">dangerous</a>" 108level permission data or capabilities without permission with an app installed 109on the device 110<li>Local temporary denial-of-service (can be resolved only through a factory 111reset) 112</ul> 113</td> 114 </tr> 115 <tr> 116 <td><strong>Low</strong></td> 117 <td> 118<ul> 119<li>Access to "<a 120href="http://developer.android.com/guide/topics/manifest/permission-element.html#plevel">normal</a>" 121level permission capabilities without permission with an app installed on the 122device 123<li>Local temporary denial-of-service (can be resolved by booting the device into 124Safe Mode and removing the problem application) 125</ul> 126</td> 127 </tr> 128</table> 129 130<p>Though there are many types of software bugs outside of the security 131vulnerabilities detailed above, bugs reported are evaluated on a 132case-by-base basis to determine what security impact they have.</p> 133 134<p>The Android security team may also adjust the severity of a vulnerability if it 135is determined the risk to users is higher or lower than the guidelines suggest. 136For example, if a certain piece of data is available only to apps with "system" 137level access but the data itself is not sensitive, the Android security 138team may consider it only a low-severity vulnerability.</p> 139 140<h4 id=local_vs_remote>Local vs. remote</h4> 141 142<p>A remote attack vector indicates the bug could be exploited without installing 143an app or without physical access to the device. This includes bugs that could 144be triggered by browsing to a web page, reading an email, receiving an SMS 145message, or connecting to a hostile network. For the purpose of our severity 146ratings, the Android security team also considers "proximal" attack vectors as 147remote. These include bugs that can be exploited only by an attacker who is 148physically near the target device, for example a bug that requires sending 149malformed Wi-Fi or Bluetooth packets.</p> 150 151<p>Local attacks require the victim to install an app. For the purpose of severity 152ratings, the Android security team also considers physical attack vectors as 153local. These include bugs that can be exploited only by an attacker who has 154physical access to the device, for example a bug in a lock screen or one that 155requires plugging in a USB cable. The Android security team also considers 156NFC-based attacks as local.</p> 157 158<h4 id=high_privilege_levels>Severity of vulnerabilities that affect high privilege levels</h4> 159 160<p>The Android security team will usually drop the severity rating for a bug that 161already requires executing code at a high privilege level. For example, a bug 162in a kernel driver accessible only from a privileged service that 163requires first compromising the service. In this case, the Android security 164team may drop the severity from "high" to "moderate."</p> 165 166<h4 id=severity_of_kernel_compromises>Severity of kernel compromises</h4> 167 168<p>Whether a vulnerability that compromises the kernel is considered "high" or 169"critical" depends on the device and the version of Android. On devices with a 170TEE (or TrustZone) and <a 171href="{@docRoot}security/verifiedboot/index.html">verified 172boot</a>, a kernel compromise is considered "high" because exploiting it won't 173allow permanently affecting the operation of the device unless a vulnerability is 174discovered in the TEE or verified boot implementation. In general, if the 175result of a compromise can be remediated with a factory reset, it's "high" or 176lower.</p> 177 178<p>However, on older devices without verified boot, a kernel compromise can result 179in permanent device compromise if SELinux is disabled and the system partition 180is modified. On that device, a kernel compromise is considered "critical" 181because remediation requires re-flashing the device's firmware image.</p> 182 183<h3 id=affected_component>Affected component</h3> 184 185<p>The development team responsible for fixing the bug depends on which component 186the bug is in. It could be a core component of the Android platform, a kernel 187driver supplied by an original equipment manufacturer (OEM), or one of the 188pre-loaded apps on Nexus devices.</p> 189 190<p>Bugs in AOSP code are fixed by the Android engineering team. Low-severity bugs, 191bugs in certain components, or bugs that are already publicly known may be 192fixed directly in the publicly available AOSP master branch; otherwise they're 193fixed in our internal repositories first.</p> 194 195<p>The component is also a factor in how users get updates. A bug in the framework 196or kernel will require an over-the-air (OTA) firmware update that each OEM will 197need to push. A bug in an app or library published in Google Play (e.g., Gmail, 198Google Play Services, WebView in Lollipop and later versions) can be sent to 199Android users as an update from Google Play. </p> 200 201<h2 id=notifying_partners>Notifying partners</h2> 202 203<p>When a moderate or higher severity security vulnerability in AOSP is fixed, 204we'll notify <a href="http://www.openhandsetalliance.com/">Open Handset 205Alliance</a> members with the details of the issue and provide patches for the 206most recent three Android releases. The Android security team currently 207provides patches for Android versions 4.4 (KitKat), 5.0 (Lollipop), and 5.1 208(Lollipop MR1). This list of backport-supported versions changes with each new 209Android release.</p> 210 211<h2 id=releasing_code_to_aosp>Releasing code to AOSP</h2> 212 213<p>If the security bug is in an AOSP component, the fix will be pushed out to AOSP 214after the OTA is released to users. Fixes for low-severity issues may be 215submitted directly to the AOSP master branch before a fix is available.</p> 216 217<h2 id=android_updates>Receiving Android updates</h2> 218 219<p>Updates to the Android system are generally delivered to devices through 220OTA update packages. These updates may come from the OEM who 221produced the device or the carrier who provides service to the device. Google 222Nexus device updates come from the Google Nexus team after going through a 223carrier technical acceptance (TA) testing procedure. Google also publishes <a 224href="https://developers.google.com/android/nexus/images">Nexus factory 225images</a> that can be side-loaded to devices.</p> 226 227<h2 id=updating_google_services>Updating Google services</h2> 228 229<p>In addition to providing patches for security bugs, the Android security team 230also review security bugs to determine if there are other ways to protect 231users. For example, Google Play scans all applications and will remove any 232application that attempts to exploit a security bug. For applications installed 233from outside of Google Play, devices with Google Play Services may also use the 234<a href="https://support.google.com/accounts/answer/2812853">Verify Apps</a> 235feature to warn users about applications that may be potentially harmful.</p> 236 237<h2 id=other_resources>Other resources</h2> 238 239<p>Information for Android application developers: <a 240href="https://developer.android.com">https://developer.android.com</a></p> 241 242<p>Security information exists throughout the Android Open Source and Developer 243sites. Good places to start:<br> 244<a href="https://source.android.com/security/index.html">https://source.android.com/security/index.html</a><br> 245<a href="https://developer.android.com/training/articles/security-tips.html">https://developer.android.com/training/articles/security-tips.html</a></p> 246 247<p>Community resource for discussion about Android security: <a 248href="https://groups.google.com/forum/?fromgroups#!forum/android-security-discuss">https://groups.google.com/forum/?fromgroups#!forum/android-security-discuss</a></p> 249