Home | History | Annotate | Download | only in overview
      1 page.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
     29 discovered in the Android platform and many of the core Android apps bundled
     30 with Android devices.</p>
     31 
     32 <p>The Android security team finds security vulnerabilities through internal
     33 research and also responds to bugs reported by third parties. Sources of
     34 external bugs include issues reported through the Android Open Source
     35 Project (AOSP) <a
     36 href="https://code.google.com/p/android/issues/entry?template=Security%20bug%20report">Security
     37 bug report</a> template, published and pre-published academic research,
     38 upstream open source project maintainers, notifications from our device
     39 manufacturer partners, and publicly disclosed issues posted on blogs or social
     40 media.</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
     45 security team of potential security issues through the AOSP bug tracker <a
     46 href="https://code.google.com/p/android/issues/entry?template=Security%20bug%20report">Security
     47 bug report</a> template.</p>
     48 
     49 <p>Bugs marked as security issues are not externally visible, but they may
     50 eventually be made visible after the issue is evaluated or resolved. If you
     51 plan to submit a patch or Compatibility Test Suite (CTS) test to resolve a
     52 security issue, please attach it to the bug report and wait for a response
     53 before 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
     58 of the bug and which component of Android is affected. The severity determines
     59 how the issue is prioritized, and the component determines who fixes the bug,
     60 who 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
     65 a bug was successfully exploited. Use the following criteria to determine the
     66 severity:</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
     79 third-party apps cannot obtain)
     80 <li>Local permanent device compromise (device cannot be repaired without
     81 re-flashing the entire operating system, such as a  verified boot or Trusted
     82 Execution Environment/TEE compromise)
     83 <li>Remote permanent denial of service (inoperability, either completely permanent
     84 or 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
     93 third-party apps can obtain through installation)
     94 <li>Local access to system/signature-level permission data or capabilities without
     95 permission
     96 <li>Local permanent denial-of-service (inoperability, either completely permanent
     97 or 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
    107 href="http://developer.android.com/guide/topics/manifest/permission-element.html#plevel">dangerous</a>"
    108 level permission data or capabilities without permission with an app installed
    109 on the device
    110 <li>Local temporary denial-of-service (can be resolved only through a factory
    111 reset)
    112 </ul>
    113 </td>
    114  </tr>
    115  <tr>
    116     <td><strong>Low</strong></td>
    117     <td>
    118 <ul>
    119 <li>Access to "<a
    120 href="http://developer.android.com/guide/topics/manifest/permission-element.html#plevel">normal</a>"
    121 level permission capabilities without permission with an app installed on the
    122 device
    123 <li>Local temporary denial-of-service (can be resolved by booting the device into
    124 Safe 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
    131 vulnerabilities detailed above, bugs reported are evaluated on a
    132 case-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
    135 is determined the risk to users is higher or lower than the guidelines suggest.
    136 For example, if a certain piece of data is available only to apps with "system"
    137 level access but the data itself is not sensitive, the Android security
    138 team 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
    143 an app or without physical access to the device. This includes bugs that could
    144 be triggered by browsing to a web page, reading an email, receiving an SMS
    145 message, or connecting to a hostile network. For the purpose of our severity
    146 ratings, the Android security team also considers "proximal" attack vectors as
    147 remote. These include bugs that can be exploited only by an attacker who is
    148 physically near the target device, for example a bug that requires sending
    149 malformed Wi-Fi or Bluetooth packets.</p>
    150 
    151 <p>Local attacks require the victim to install an app. For the purpose of severity
    152 ratings, the Android security team also considers physical attack vectors as
    153 local. These include bugs that can be exploited only by an attacker who has
    154 physical access to the device, for example a bug in a lock screen or one that
    155 requires plugging in a USB cable. The Android security team also considers
    156 NFC-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
    161 already requires executing code at a high privilege level. For example, a bug
    162 in a kernel driver accessible only from a privileged service that
    163 requires first compromising the service. In this case, the Android security
    164 team 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
    170 TEE (or TrustZone) and <a
    171 href="{@docRoot}security/verifiedboot/index.html">verified
    172 boot</a>, a kernel compromise is considered "high" because exploiting it won't
    173 allow permanently affecting the operation of the device unless a vulnerability is
    174 discovered in the TEE or verified boot implementation. In general, if the
    175 result of a compromise can be remediated with a factory reset, it's "high" or
    176 lower.</p>
    177 
    178 <p>However, on older devices without verified boot, a kernel compromise can result
    179 in permanent device compromise if SELinux is disabled and the system partition
    180 is modified. On that device, a kernel compromise is considered "critical"
    181 because 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
    186 the bug is in. It could be a core component of the Android platform, a kernel
    187 driver supplied by an original equipment manufacturer (OEM), or one of the
    188 pre-loaded apps on Nexus devices.</p>
    189 
    190 <p>Bugs in AOSP code are fixed by the Android engineering team. Low-severity bugs,
    191 bugs in certain components, or bugs that are already publicly known may be
    192 fixed directly in the publicly available AOSP master branch; otherwise they're
    193 fixed 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
    196 or kernel will require an over-the-air (OTA) firmware update that each OEM will
    197 need to push. A bug in an app or library published in Google Play (e.g., Gmail,
    198 Google Play Services, WebView in Lollipop and later versions) can be sent to
    199 Android 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,
    204 we'll notify <a href="http://www.openhandsetalliance.com/">Open Handset
    205 Alliance</a> members with the details of the issue and provide patches for the
    206 most recent three Android releases. The Android security team currently
    207 provides 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
    209 Android 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
    214 after the OTA is released to users. Fixes for low-severity issues may be
    215 submitted 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
    220 OTA update packages. These updates may come from the OEM who
    221 produced the device or the carrier who provides service to the device. Google
    222 Nexus device updates come from the Google Nexus team after going through a
    223 carrier technical acceptance (TA) testing procedure. Google also publishes <a
    224 href="https://developers.google.com/android/nexus/images">Nexus factory
    225 images</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
    230 also review security bugs to determine if there are other ways to protect
    231 users. For example, Google Play scans all applications and will remove any
    232 application that attempts to exploit a security bug. For applications installed
    233 from 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>
    235 feature 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
    240 href="https://developer.android.com">https://developer.android.com</a></p>
    241 
    242 <p>Security information exists throughout the Android Open Source and Developer
    243 sites. 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
    248 href="https://groups.google.com/forum/?fromgroups#!forum/android-security-discuss">https://groups.google.com/forum/?fromgroups#!forum/android-security-discuss</a></p>
    249