Who are we?
The Devices & Services Security team is responsible for managing vulnerabilities discovered in Google products (Pixel, Nest, Home & Fitbit) and many of the core services and apps bundled with these devices.
Reporting Vulnerabilities
Any developer, device user, or security researcher can notify the Devices & Services Security team of potential security issues through our vulnerability reporting form that is part of the Google Devices Security Reward Program. Bugs marked as security issues aren't externally visible, but they may eventually be made visible after the issue is evaluated or resolved.
Triaging Bugs
The first task in handling a security vulnerability is to identify the severity of the bug and which component of the device is affected. The severity level 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.
Vulnerability Disclosures
For software apps and services associated with our devices, we follow Google’s vulnerability disclosure deadline. For device and system software components, some vulnerabilities may require longer remediation and disclosure timelines (e.g., due to dependencies with components delivered by Silicon vendors).
Severity
| Severity |
Consequence of successful exploitation |
| Critical |
- Arbitrary code execution in the TEE or SE
- Bypass of software mechanisms designed to prevent safety-related software or hardware components from malfunctioning (for example, thermal protections)
- Remote access to sensitive credentials used for remote service authentication (for example, account passwords or bearer tokens)
- Remote arbitrary code execution within the cellular baseband context with no user interaction (for example, exploiting a bug in the cellular radio service)
- Remote arbitrary code execution in a privileged context, the bootloader chain, THB, or the OS Kernel
- Remote bypass of user interaction requirements on package installation or equivalent behavior
- Remote bypass of user interaction requirements for core developer, security, or privacy settings
- Remote persistent denial of service (permanent, requiring reflashing the entire operating system, or a factory reset)
- Remote secure boot bypass
- Unauthorized access to data secured by the SE including access enabled by weak keys in the SE.
|
| High |
- A complete bypass of a core security feature (for example, SELinux, FBE, or seccomp)
- A general bypass for a defense in depth or exploit mitigation technology in the bootloader chain, TEE, or SE
- A general bypass for operating system protections that reveal memory or file contents across app, user, or profile boundaries
- Attacks against an SE that result in downgrading to a less secure implementation
- Bypass of device protection/factory reset protection/carrier restrictions
- Bypass of user interaction requirements that are secured by the TEE
- Cryptographic vulnerability that allows for attacks against end-to-end protocols, including attacks against transport layer security (TLS) and Bluetooth (BT).
- Local access to sensitive credentials used for remote service authentication (for example, account passwords or bearer tokens)
- Local arbitrary code execution in a privileged context, the bootloader chain, THB, or the OS Kernel
- Local secure boot bypass
- Lockscreen bypass
- Local bypass of user interaction requirements for core developer, security, or privacy settings
- Local bypass of user interaction requirements on package installation or equivalent behavior
- Local persistent denial of service (permanent, requiring reflashing the entire operating system, or factory reset)
- Remote access to protected data (that is, data that is limited to a privileged context)
- Remote arbitrary code execution in an unprivileged context
- Remote prevention of access to cellular or Wi-Fi service with no user interaction (for example, crashing the cellular radio service with a malformed packet)
- Remote bypass of user interaction requirements (access to functionality or data that should require either user initiation or user permission)
- Targeted prevention of access to emergency services
- Transmitting sensitive information over an insecure network protocol (for example, HTTP and unencrypted Bluetooth) when the requester expects a secure transmission. Note that this doesn't apply to Wi-Fi encryption (such as, WEP)
- Unauthorized access to data secured by the TEE including access enabled by weak keys in the TEE
|
| Medium |
- A general bypass for a defense in depth or exploit mitigation technology in a privileged context, THB, or the OS Kernel
- A general bypass for operating system protections that reveal process state or metadata across app, user, or profile boundaries
- Bypassing Wi-Fi encryption or authentication
- Cryptographic vulnerability in standard crypto primitives that allows leaking of plaintext (not primitives used in TLS)
- Local access to protected data (that is, data that is limited to a privileged context)
- Local arbitrary code execution in an unprivileged context
- Local bypass of user interaction requirements (access to functionality or data that would normally require either user initiation or user permission)
- Remote access to unprotected data (that is, data normally accessible to any locally installed app)
- Remote arbitrary code execution in a constrained context
- Remote temporary device denial of service (remote hang or reboot)
|
| Low |
- A general bypass for a user level defense in depth or exploit mitigation technology in an unprivileged context
- Bypass of a normal protection level permission
- Cryptographic vulnerability in non-standard usage
- General bypass of on-device personalization features such as Voice Match or Face Match
-
- Incorrect documentation that may lead to a security vulnerability
- Local arbitrary code execution in a constrained context
- System-defined text that includes a misleading description that creates a false security expectation
|