Posted by Wedson Almeida Filho, Android Team In our previous post, we announced that Android now supports the Rust programming language for developing the OS itself. Related to this, we are also participating in the effort to evaluate the use of Rust …Read More Rust in the Linux kernel
Posted by Jeff Vander Stoep and Stephen Hines, Android Team Correctness of code in the Android platform is a top priority for the security, stability, and quality of each Android release. Memory safety bugs in C and C++ continue to be the most-difficu…Read More Rust in the Android platform
Posted by Arvind Kumar Sugumar, Software Engineer, Android Team(Note: We’ve updated this post to reflect that the API works by collecting 3.25 bytes of the hashed username)With the proliferation of digital services in our lives, it’s more important tha…Read More New Password Checkup Feature Coming to Android
Posted by Anna Hupa, Senior Strategist, Vulnerability Rewards TeamDespite the challenges of this unprecedented year, our vulnerability researchers have achieved more than ever before, partnering with our Vulnerability Reward Programs (VRPs) to protect …Read More Vulnerability Reward Program: 2020 Year in Review
Posted by Kevin Deus, Joel Galenson, Billy Lau and Ivan Lozano, Android Security & Privacy TeamThe Android platform team is committed to securing Android for every user across every device. In addition to monthly security updates to patch vulnerabi…Read More Data Driven Security Hardening in Android
Posted by David Zeuthen, Shawn Willden and René Mayrhofer, Android Security and Privacy team In the United States and other countries a Driver’s License is not only used to convey driving privileges, it is also commonly used to prove identity or person…Read More Privacy-preserving features in the Mobile Driving License
Posted by Kylie McRoberts, Program Manager and Alec Guertin, Security Engineer
Google’s Android Security & Privacy team has launched the Android Partner Vulnerability Initiative (APVI) to manage security issues specific to Android OEMs. The APVI is designed to drive remediation and provide transparency to users about issues we have discovered at Google that affect device models shipped by Android partners.
Another layer of security
Android incorporates industry-leading security features and every day we work with developers and device implementers to keep the Android platform and ecosystem safe. As part of that effort, we have a range of existing programs to enable security researchers to report security issues they have found. For example, you can report vulnerabilities in Android code via the Android Security Rewards Program (ASR), and vulnerabilities in popular third-party Android apps through the Google Play Security Rewards Program. Google releases ASR reports in Android Open Source Project (AOSP) based code through the Android Security Bulletins (ASB). These reports are issues that could impact all Android based devices. All Android partners must adopt ASB changes in order to declare the current month’s Android security patch level (SPL). But until recently, we didn’t have a clear way to process Google-discovered security issues outside of AOSP code that are unique to a much smaller set of specific Android OEMs. The APVI aims to close this gap, adding another layer of security for this targeted set of Android OEMs.
Improving Android OEM device security
The APVI covers Google-discovered issues that could potentially affect the security posture of an Android device or its user and is aligned to ISO/IEC 29147:2018 Information technology — Security techniques — Vulnerability disclosure recommendations. The initiative covers a wide range of issues impacting device code that is not serviced or maintained by Google (these are handled by the Android Security Bulletins).
Protecting Android users
The APVI has already processed a number of security issues, improving user protection against permissions bypasses, execution of code in the kernel, credential leaks and generation of unencrypted backups. Below are a few examples of what we’ve found, the impact and OEM remediation efforts.
In some versions of a third-party pre-installed over-the-air (OTA) update solution, a custom system service in the Android framework exposed privileged APIs directly to the OTA app. The service ran as the system user and did not require any permissions to access, instead checking for knowledge of a hardcoded password. The operations available varied across versions, but always allowed access to sensitive APIs, such as silently installing/uninstalling APKs, enabling/disabling apps and granting app permissions. This service appeared in the code base for many device builds across many OEMs, however it wasn’t always registered or exposed to apps. We’ve worked with impacted OEMs to make them aware of this security issue and provided guidance on how to remove or disable the affected code.
checkUidPermission method in the
PackageManagerService class was modified in the framework code for some devices to allow special permissions access to some apps. In one version, the method granted apps with the shared user ID
com.google.uid.shared any permission they requested and apps signed with the same key as the
com.google.android.gsf package any permission in their manifest. Another version of the modification allowed apps matching a list of package names and signatures to pass runtime permission checks even if the permission was not in their manifest. These issues have been fixed by the OEMs.
Keep an eye out at https://bugs.chromium.org/p/apvi/ for future disclosures of Google-discovered security issues under this program, or find more information there on issues that have already been disclosed.
Acknowledgements: Scott Roberts, Shailesh Saini and Łukasz Siewierski, Android Security and Privacy Team
Read More Announcing the launch of the Android Partner Vulnerability Initiative
Posted by Haining Chen, Vishwath Mohan, Kevin Chyn and Liz Louis, Android Security Team[Cross-posted from the Android Developers Blog] As phones become faster and smarter, they play increasingly important roles in our lives, functioning as our extended…Read More Lockscreen and Authentication Improvements in Android 11
Posted by Eugene Liderman and Xevi Miro Bruix, Android Security and Privacy Team Trust is very important when it comes to the relationship between a user and their smartphone. While phone functionality and design can enhance the user experience, securi…Read More Pixel 4a is the first device to go through ioXt at launch
Posted by Platform Hardening Team In Android 11 we continue to increase the security of the Android platform. We have moved to safer default settings, migrated to a hardened memory allocator, and expanded the use of compiler mitigations that defend a…Read More System hardening in Android 11
Posted by Charmaine D’Silva, Product Lead, Android Privacy and Framework, Narayan Kamath, Engineering Lead, Android Privacy and Framework, Stephan Somogyi, Product Lead, Android Security and Sudhi Herle, Engineering Lead, Android Security This blog po…Read More 11 Weeks of Android: Privacy and Security