359 lines
15 KiB
HTML
359 lines
15 KiB
HTML
<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.
|
|
-->
|
|
|
|
|
|
|
|
<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>
|
|
<col width="30%">
|
|
<col width="70%">
|
|
<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>Trusted Computing Base (TCB)</td>
|
|
<td>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), or is one of a handful of user services
|
|
that is considered kernel equivalent: <code>init</code>, <code>ueventd</code>,
|
|
and <code>vold</code>.</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>Arbitrary code execution in the TEE</li>
|
|
<li>Remote arbitrary code execution in a privileged process or the TCB</li>
|
|
<li>Remote permanent denial of service (device inoperability: completely
|
|
permanent or requiring re-flashing the entire operating system)</li>
|
|
<li>Remote bypass of user interaction requirements on package installation or
|
|
equivalent behavior</li>
|
|
<li>Secure Boot bypass</li>
|
|
</ul>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td><strong>High</strong></td>
|
|
<td>
|
|
<ul>
|
|
<li>Remote arbitrary code execution in an unprivileged process</li>
|
|
<li>Arbitrary local code execution in a privileged process or the TCB</li>
|
|
<li>Unauthorized access to data secured by the TEE</li>
|
|
<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>
|
|
<li>Local permanent denial of service (device inoperability: completely
|
|
permanent or requiring re-flashing the entire operating system)</li>
|
|
<li>Remote temporary device denial of service (remote hang or reboot)</li>
|
|
<li>Remote bypass of user interaction requirements (access to functionality that
|
|
would normally require either user initiation or user permission)</li>
|
|
<li>Local bypass of user interaction requirements for any developer or security
|
|
settings modifications</li>
|
|
<li>A general bypass for operating system protections that isolate application
|
|
data from other applications</li>
|
|
<li>A general bypass for operating system protections that isolate users or
|
|
profiles from one another</li>
|
|
<li>Cryptographic Vulnerability in Standard TLS that allows for
|
|
man-in-the-middle attacks</li>
|
|
<li>Lockscreen bypass</li>
|
|
</ul>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td><strong>Moderate</strong></td>
|
|
<td>
|
|
<ul>
|
|
<li>Remote arbitrary code execution in a constrained process</li>
|
|
<li>Local arbitrary code execution in an unprivileged process</li>
|
|
<li>A general bypass for a defense in depth or exploit mitigation technology in
|
|
a privileged process, the TCB, or the TEE</li>
|
|
<li>Bypass of restrictions on a constrained process</li>
|
|
<li>Remote access to unprotected data (data normally accessible to any locally
|
|
installed app)</li>
|
|
<li>Local access to protected data (data normally accessible only to locally
|
|
installed apps that request permission, or that is limited to a privileged
|
|
process)</li>
|
|
<li>Local bypass of user interaction requirements (access to functionality that
|
|
would normally require either user initiation or user permission)</li>
|
|
<li>Local permanent denial of service (device requires a factory reset)</li>
|
|
<li>Cryptographic Vulnerability in standard crypto primitives that allows
|
|
leaking of plaintext (not primitives used in TLS)</li>
|
|
<li>Bypass of Device Protection/ Factory Reset Protection</li>
|
|
<li>Bypass of Carrier Restrictions</li>
|
|
<li>Targeted prevention of access to emergency services</li>
|
|
</ul>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td><strong>Low</strong></td>
|
|
<td>
|
|
<ul>
|
|
<li>Local arbitrary code execution in a constrained process</li>
|
|
<li>Cryptographic Vulnerability in non-standard usage</li>
|
|
<li>A general bypass for a user level defense in depth or exploit
|
|
mitigation technology in an unprivileged process</li>
|
|
</ul>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td><strong>No Security Impact (NSI)</strong></td>
|
|
<td>
|
|
<ul>
|
|
<li>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</li>
|
|
</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>
|
|
<tr>
|
|
<td>Compiler or platform configurations mitigate a vulnerability in the
|
|
source code</td>
|
|
<td>Moderate Severity if the underlying vulnerability is Moderate or higher</td>
|
|
</tr>
|
|
<tr>
|
|
<td>Requires tamper-evident physical access</td>
|
|
<td>-2 Severity</td>
|
|
</tr>
|
|
<tr>
|
|
<td>If no SELinux domain can conduct the operation under the Google-provided
|
|
SEPolicy</td>
|
|
<td>No Security Impact</td>
|
|
</tr>
|
|
</table>
|
|
|
|
<p class="note">
|
|
<strong>Note</strong>: A CVE may not be issued for issues assessed as Low or NSI.
|
|
</p>
|
|
|
|
|
|
|
|
<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 security vulnerability in AOSP is fixed in an Android Security
|
|
Bulletin, we'll notify Android partners of issue details and provide patches.
|
|
The Android security team currently provides patches for Android versions 4.4
|
|
(KitKat) and above. 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="/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="/security/reports/Google_Android_Security_2016_Report_Final.pdf">
|
|
Android Security 2016 Year In Review</a></li>
|
|
<li><a href="/security/reports/Google_Android_Security_2015_Report_Final.pdf">
|
|
Android Security 2015 Year In Review</a></li>
|
|
<li><a href="/security/reports/Google_Android_Security_2014_Report_Final.pdf">
|
|
Android Security 2014 Year In Review</a></li>
|
|
<li><a href="/security/reports/Android_WhitePaper_Final_02092016.pdf">
|
|
Android Security white paper</a></li>
|
|
<li><a href="/security/reports/Google_Android_Security_PHA_classifications.pdf">
|
|
Classifications for Potentially Harmful Applications</a></li>
|
|
</ul>
|
|
|
|
<h3 id=slides>Presentations</h3>
|
|
<p>The Android Security team presents at various conferences and talks. Here are some of their slides:</p>
|
|
<ul>
|
|
<li><a href="/security/reports/Android-Bootcamp-2016-Verified-Boot-and-Encryption.pdf">
|
|
Verified boot and encryption</a></li>
|
|
<li><a href="/security/reports/Android-Bootcamp-2016-SafetyNet.pdf">
|
|
SafetyNet</a></li>
|
|
<li><a href="/security/reports/Android-Bootcamp-2016-New-App-Lifecycle-for-Encryption.pdf">
|
|
New app life cycle for encryption</a></li>
|
|
<li><a href="/security/reports/Android-Bootcamp-2016-Keeping-Google-Play-safe.pdf">
|
|
Keeping Google Play safe</a></li>
|
|
<li><a href="/security/reports/Android-Bootcamp-2016-Defense-in-depth-efforts.pdf">
|
|
Defense in depth efforts</a></li>
|
|
<li><a href="/security/reports/Android-Bootcamp-2016-Android-Keystore-Attestation.pdf">
|
|
Keystore attestation</a></li>
|
|
<li><a href="/security/reports/Android-Bootcamp-2016-Android-Attack-Team.pdf">
|
|
Android attack team</a></li>
|
|
</ul>
|
|
</body>
|
|
</html>
|