Author Archives: Edward Fernandez

How we fought bad apps and bad actors in 2022

Posted by Anu Yamunan and Khawaja Shams (Android Security and Privacy Team), and Mohet Saxena (Compute Trust and Safety)

Keeping Google Play safe for users and developers remains a top priority for Google. Google Play Protect continues to scan billions of installed apps each day across billions of Android devices to keep users safe from threats like malware and unwanted software.

In 2022, we prevented 1.43 million policy-violating apps from being published on Google Play in part due to new and improved security features and policy enhancements — in combination with our continuous investments in machine learning systems and app review processes. We also continued to combat malicious developers and fraud rings, banning 173K bad accounts, and preventing over $2 billion in fraudulent and abusive transactions. We’ve raised the bar for new developers to join the Play ecosystem with phone, email, and other identity verification methods, which contributed to a reduction in accounts used to publish violative apps. We continued to partner with SDK providers to limit sensitive data access and sharing, enhancing the privacy posture for over one million apps on Google Play.

With strengthened Android platform protections and policies, and developer outreach and education, we prevented about 500K submitted apps from unnecessarily accessing sensitive permissions over the past 3 years.

Developer Support and Collaboration to Help Keep Apps Safe

As the Android ecosystem expands, it’s critical for us to work closely with the developer community to ensure they have the tools, knowledge, and support to build secure and trustworthy apps that respect user data security and privacy.

In 2022, the App Security Improvements program helped developers fix ~500K security weaknesses affecting ~300K apps with a combined install base of approximately 250B installs. We also launched the Google Play SDK Index to help developers evaluate an SDK’s reliability and safety and make informed decisions about whether an SDK is right for their business and their users. We will keep working closely with SDK providers to improve app and SDK safety, limit how user data is shared, and improve lines of communication with app developers.


We also recently launched new features and resources to give developers a better policy experience. We’ve expanded our Helpline pilot to give more developers direct policy phone support. And we piloted the Google Play Developer Community so more developers can discuss policy questions and exchange best practices on how to build safe apps.

More Stringent App Requirements and Guidelines

In addition to the Google Play features and policies that are central to providing a safe experience for users, each Android OS update brings privacy, security, and user experience improvements. To ensure users realize the full benefits of these advances — and to maintain the trusted experience people expect on Google Play — we collaborate with developers to ensure their apps work seamlessly on newer Android versions. With the new Target API Level policy, we’re strengthening user security and privacy by protecting users from installing apps that may not have the full set of privacy and security features offered by the latest versions of Android.

This past year, we rolled out new license requirements for personal loan apps in key geographies – Kenya, Nigeria, and Philippines – with more stringent requirements for loan facilitator apps in India to combat fraud. We also clarified that our impersonation policy prohibits the impersonation of an entity or organization – helping to give users more peace of mind that they are downloading the app they’re looking for.

We are also working to help fight fraudulent and malicious ads on Google Play. With an updated ads policy for developers, we are providing key guidelines that will improve the in-app user experience and prohibit unexpected full screen interstitial ads. This update is inspired by the Mobile Apps Experiences - Better Ads Standards.

Improving Data Transparency, Security Controls and Tools

We launched the Data safety section in Google Play last year to give users more clarity on how their app data is being collected, shared, and protected. We’re excited to work with developers on enhancing the Data safety section to share their data collection, sharing, and safety practices with their users.

In 2022, the Google Play Store was the first commercial app store to recognize and display a badge for any app that has completed an independent security review through App Defense Alliance’s Mobile App Security Assessment (MASA). The badge is displayed within an app’s respective Data Safety section. MASA leverages OWASP’s Mobile Application Security Verification Standard, which is the most widely adopted set of security requirements for mobile applications. We’re seeing strong developer interest in MASA with widely used apps across major app categories, e.g., Roblox, Uber, PayPal, Threema, YouTube, and many more.

This past year, we also expanded the App Defense Alliance, an alliance of partners with a mission to protect Android users from bad apps through shared intelligence and coordinated detection. McAfee and Trend Micro joined Google, ESET, Lookout, and Zimperium, to reduce the risk of app-based malware and better protect Android users.

We’ve also continued to enhance protections for developers and their apps, such as hardening Play Integrity API with KeyMint and Remote Key Provisioning.

Bringing Continuous Security and Privacy Enhancements to Pixel Users

For Pixel users, we added more powerful features to help keep our users safe. The new security and privacy settings have been launched to all Pixel devices running Android 13, improving the security and privacy posture for millions of users’ around the world every month. Private Compute Core also allows Pixel phones to detect harmful apps in a privacy preserving way.

Looking Ahead

We remain committed to keeping Google Play and our ecosystem of users and developers safe, and we look forward to many exciting security and safety announcements in 2023.

Thank you and goodbye to the Chrome Cleanup Tool

Posted by Jasika Bawa, Chrome Security Team

Starting in Chrome 111 we will begin to turn down the Chrome Cleanup Tool, an application distributed to Chrome users on Windows to help find and remove unwanted software (UwS).

Origin story

The Chrome Cleanup Tool was introduced in 2015 to help users recover from unexpected settings changes, and to detect and remove unwanted software. To date, it has performed more than 80 million cleanups, helping to pave the way for a cleaner, safer web.

A changing landscape

In recent years, several factors have led us to reevaluate the need for this application to keep Chrome users on Windows safe.

First, the user perspective – Chrome user complaints about UwS have continued to fall over the years, averaging out to around 3% of total complaints in the past year. Commensurate with this, we have observed a steady decline in UwS findings on users' machines. For example, last month just 0.06% of Chrome Cleanup Tool scans run by users detected known UwS.

Next, several positive changes in the platform ecosystem have contributed to a more proactive safety stance than a reactive one. For example, Google Safe Browsing as well as antivirus software both block file-based UwS more effectively now, which was originally the goal of the Chrome Cleanup Tool. Where file-based UwS migrated over to extensions, our substantial investments in the Chrome Web Store review process have helped catch malicious extensions that violate the Chrome Web Store's policies.

Finally, we've observed changing trends in the malware space with techniques such as Cookie Theft on the rise – as such, we've doubled down on defenses against such malware via a variety of improvements including hardened authentication workflows and advanced heuristics for blocking phishing and social engineering emails, malware landing pages, and downloads.

What to expect

Starting in Chrome 111, users will no longer be able to request a Chrome Cleanup Tool scan through Safety Check or leverage the "Reset settings and cleanup" option offered in chrome://settings on Windows. Chrome will also remove the component that periodically scans Windows machines and prompts users for cleanup should it find anything suspicious.

Even without the Chrome Cleanup Tool, users are automatically protected by Safe Browsing in Chrome. Users also have the option to turn on Enhanced protection by navigating to chrome://settings/security – this mode substantially increases protection from dangerous websites and downloads by sharing real-time data with Safe Browsing.

While we'll miss the Chrome Cleanup Tool, we wanted to take this opportunity to acknowledge its role in combating UwS for the past 8 years. We'll continue to monitor user feedback and trends in the malware ecosystem, and when adversaries adapt their techniques again – which they will – we'll be at the ready.

As always, please feel free to send us feedback or find us on Twitter @googlechrome.

8 ways to secure Chrome browser for Google Workspace users

Posted by Kiran Nair, Product Manager, Chrome Browser

1. Bring Chrome under Cloud Management

Your journey towards keeping your Google Workspace users and data safe, starts with bringing your Chrome browsers under Cloud Management at no additional cost. Chrome Browser Cloud Management is a single destination for applying Chrome Browser policies and security controls across Windows, Mac, Linux, iOS and Android. You also get deep visibility into your browser fleet including which browsers are out of date, which extensions your users are using and bringing insight to potential security blindspots in your enterprise.

Managing Chrome from the cloud allows Google Workspace admins to enforce enterprise protections and policies to the whole browser on fully managed devices, which no longer requires a user to sign into Chrome to have policies enforced. You can also enforce policies that apply when your managed users sign in to Chrome browser on any Windows, Mac, or Linux computer (via Chrome Browser user-level management) --not just on corporate managed devices.

This enables you to keep your corporate data and users safe, whether they are accessing work resources from fully managed, personal, or unmanaged devices used by your vendors.

Getting started is easy. If your organization hasn’t already, check out this guide for steps on how to enroll your devices.

2. Enforce built-in protections against Phishing, Ransomware & Malware

Chrome uses Google’s Safe Browsing technology to help protect billions of devices every day by showing warnings to users when they attempt to navigate to dangerous sites or download dangerous files. Safe Browsing is enabled by default for all users when they download Chrome. As an administrator, you can prevent your users from disabling Safe Browsing by enforcing the SafeBrowsingProtectionLevel policy.

Over the past few years, we’ve seen threats on the web becoming increasingly sophisticated. Turning on Enhanced Safe Browsing will substantially increase protection from dangerous websites, malicious downloads and extensions. For the best protections against web based attacks Google has to offer, enforce Enhanced Safe Browsing for your users.

3. Enable Enterprise Credential Protections in Chrome

Enterprise password reuse introduces significant security risks. Quite often, employees reuse corporate credentials as personal logins and vice versa. Occasionally, employees even enter their corporate passwords into phishing websites. Reused employee logins give criminals easy paths to access corporate data.

Chrome Enterprise Password Reuse detection helps enterprises avoid identity theft and employee and organizational data breaches by detecting when an employee enters their corporate credentials into any other website.

Google Password Manager in Chrome also has a built-in Password Checkup feature that alerts users when Google discovers a username and password has been exposed in a public data breach.

Password alerts are surfaced in Audit Logs and Security Investigation Tool which helps admins create automated rules or take appropriate steps to mitigate this by asking users to reset their passwords.

4. Gain insights into critical security events via Audit Logs, Google Security Center or your SIEM of choice

IT teams can gain useful insights about potential security threats and events that your Google Workspace users are encountering when browsing the web using Chrome. IT teams can take preventive measures against threats through Security Reporting.

In the Google Workspace Admin console, organizations can enroll their Chrome browser and get detailed information about their browser deployment. IT teams can also set policies, manage extensions, and more. The Chrome management policies can be set to work alongside any end user-based policies that may be in place.

Once you’ve enabled Security events reporting (pictured above), you can then view reporting events within audit logs. Google Workspace Enterprise Plus or Education Plus users can use the Workspace Security Investigation Tool to identify, triage, and act on potential security threats.

As of today, Chrome can report on when users:

  • Navigate to a known malicious site.
  • Download or upload files containing known malware.
  • Reuse corporate passwords on non-approved sites.
  • Change corporate passwords after reusing them on non-approved sites.
  • Install extensions.

In addition to Google Workspace, you can also export these events into other Google Cloud products, such as Google Cloud Pub/Sub, Chronicle, or leading 3rd party products such as Splunk, Crowdstrike and PaloAlto Networks.

5. Mitigate risk by keeping your browsers up to date with latest security updates

Modern web browsers, like any other software, can have "zero day" vulnerabilities, which are undiscovered flaws in the software that can be exploited by attackers until they are identified and resolved. Fortunately, among all the browsers, Chrome is known to patch zero day vulnerabilities quickly. However, to take advantage of this, the IT team has to ensure that all browsers within the browser environment are up-to-date. Our enterprise tools provide a smooth and seamless browser update process, enabling user productivity while maintaining optimal security. By leveraging these tools, businesses can ensure their users are safe and protected from potential security threats.

  • Version Report: Easily see all the versions of Chrome in your fleet across various operating systems in a daily report.
  • Force Auto Updates in Chrome: Trigger updates to newer versions of Chrome as soon as they’re available. Force users to relaunch Chrome to take updates more rapidly using enterprise policies. This keeps users on the latest version of Chrome, with the latest security fixes.
  • Controlling legacy browser usage: Some users continue to need access to old web applications that use plugins and ActiveX technology not supported by modern browsers. Legacy Browser Support functionality is integrated into Chrome, and reduces the time users spend with less secure browsers.

6. Ensure employees only use vetted extensions

Extensions pose a large security risk. Many extensions request powerful permissions that if misused, could lead to security breaches or data loss. However, due to strong end user demand, it’s often not possible to fully block the installation of extensions.

  • Apps & Extensions usage report: Provides visibility into every Chrome extension that is installed across an enterprise’s fleet. Admins can force install or block any extension across any segment of their fleet.
  • Extensions workflow: Admins can decide under which circumstances an extension install needs to be reviewed by IT. A review workflow in the Google Admin console makes it easy for admins to review and approve install requests for specific users requesting an extension, or for their broader fleet.
  • Extensions details: Admins can see additional details about an extension’s permissions, and other relevant metadata. This info is surfaced in the Extensions list and Extensions workflow pages to make it easier for administrators to manage extensions.

7. Ensure your Google Workspace resources are only accessed from Managed Chrome Browsers with protections enabled

Context-Aware Access ensures only the right people, under the right conditions, access confidential information. Using Context-Aware Access, you can create granular access control policies for apps that access Workspace data based on attributes, such as user identity, location, device security status, and IP address.

To ensure that your Google Workspace resources are only accessed from managed Chrome browsers with protection enabled, you create custom access levels in Advanced mode, using Common Expressions Language (CEL). Learn more about managed queries in this help center article.

8. Enable BeyondCorp Enterprise Threat and Data Protections

For the organizations that want to take an even more proactive approach to data security, they can deploy BeyondCorp Enterprise to protect their information and enable data loss prevention (including control over upload, download, print, save, copy and paste), real-time phishing protection, malware deep scanning, and Zero Trust access to SaaS applications. Since BeyondCorp Enterprise is already built into Chrome, organizations can frictionlessly implement it without having to install additional agents.

Learn more about how Google supports today’s workforce with secure enterprise browsing here.

Moving Connected Device Security Standards Forward

Posted by Eugene Liderman, Director of Mobile Security Strategy, Google

As Mobile World Congress approaches, we have the opportunity to have deep and meaningful conversations across the industry about the present and future of connected device security. Ahead of the event, we wanted to take a moment to recognize and share additional details on the notable progress being made to form harmonized connected device security standards and certification initiatives that provide users with better transparency about how their sensitive data is protected.

Supporting the GSMA Working Party for Mobile Device Security Transparency

We’re pleased to support and participate in the recently announced GSMA working party, which will develop a first-of-its-kind smartphone security certification program. The program will leverage the Consumer Mobile Device Protection Profile (CMD PP) specification released by ETSI, a European Standards Development Organization (SDO), and will provide a consistent way to evaluate smartphones for critical capabilities like encryption, security updates, biometrics, networking, trusted hardware, and more.

This initiative should help address a significant gap in the market for consumers and policy makers, who will greatly benefit from a new, central security resource. Most importantly, these certification programs will evaluate connected devices across industry-accepted criteria. Widely-used devices, including smartphones and tablets, which currently do not have a familiar security benchmark or system in place, will be listed with key information on device protection capabilities to bring more transparency to users.

We hope this industry-run certification program can also benefit users and support policy makers in their work as they address baseline requirements and harmonization of standards.As policy makers consider changes through regulation and legislation, such as the UK’s Product Security and Telecommunications Infrastructure Act (PSTI), and emerging regulation like the EU Cyber Security and Cyber Resilience Acts, we share the concerns that today we are not equipped with globally recognized standards that are critical to increased security across the ecosystem. We join governments in the call to come together to ensure that we can build workable, harmonized standards to protect the security of users and mobile infrastructure today and build the resilience needed to protect our future.

The Importance of Harmonized Standards for Connected Devices

Connected devices, not just smartphones, are increasingly becoming the primary touchpoint for the most important aspects of our personal lives. From controlling the temperature of your home, to tracking your latest workout – connected devices have become embedded in our day-to-day tasks and activities. As consumers increasingly entrust more of their lives to their connected devices, they’re right to question the security protections provided and demand more transparency from manufacturers.

After we participated in a recent White House Workshop on IoT security labeling, we shared more about our commitment to security and transparency by announcing the extension of device security assessments – which started with Pixel 3 and now includes Nest, and Fitbit hardware. We have and always will strive to ensure our newly released products comply with the most prevalent security baselines that are defined by industry-recognized standards organizations. We will also remain transparent about critical security features – like how long our devices will receive security updates and our collaboration with security researchers that help us identify and fix security issues to help keep users safe.

By participating in international standards and certification programs such as our work as a member of the Connectivity Standards Alliance (Alliance), we’re working to raise the bar for the industry and develop a consistent set of security requirements that users can rely on.


New Research Continues to Help Inform Our Efforts to Establish Strong Security Standards and Labeling Practices

Last year, the Alliance formed the Product Security Working Group (PSWG). Over the past nine months, the working group has been making terrific progress on its mission to build an industry-run certification program for IoT devices that aligns with existing and future regulatory requirements to reduce fragmentation and promote harmonization.

Today, the Alliance in partnership with independent research firm Omdia, published a comprehensive research report that outlines all of the currently published and emerging global IoT security regulations and the standards baselines they map to. This critical research enables PSWG to hone its focus and efforts on harmonizing between ETSI EN 303 645 and NIST IR 8425, as these two baseline security standards were found to underpin the vast majority of the regulations outlined in the research report.

The other notable area of the report highlighted the need for transparent security labeling for connected devices, which has also become a very important industry initiative. A large majority (77%) of consumers surveyed indicated a device label that explains the privacy and security practices of the manufacturer would be important or very important to their purchasing decision. Transparent security labeling is critical in helping consumers understand which devices meet specific security standards and requirements during evaluation. We recently provided our principles for IoT security labeling and will continue to be a key contributor to efforts around providing users with transparent device security labels.

Creating Strong Connected Device Security Standards Together

It’s been inspiring to see all of the progress that the Connectivity Standards Alliance, GSMA and the industry at large has made on security standards and labeling initiatives in such a short time. It’s even more exciting to see how much collaboration there has been between both industry and the public sector on these efforts. We look forward to continuing the conversation and coordinating on these important security initiatives with policymakers, industry partners, developers and public interest advocates to bring more security and transparency to connected device users.

Vulnerability Reward Program: 2022 Year in Review

Posted by Sarah Jacobus, Vulnerability Rewards Team

It has been another incredible year for the Vulnerability Reward Programs (VRPs) at Google! Working with security researchers throughout 2022, we have been able to identify and fix over 2,900 security issues and continue to make our products more secure for our users around the world.

We are thrilled to see significant year over year growth for our VRPs, and have had yet another record breaking year for our programs! In 2022 we awarded over $12 million in bounty rewards – with researchers donating over $230,000 to a charity of their choice.

As in past years, we are sharing our 2022 Year in Review statistics across all of our programs. We would like to give a special thank you to all of our dedicated researchers for their continued work with our programs - we look forward to more collaboration in the future!

Android

The Android VRP had an incredible record breaking year in 2022 with $4.8 million in rewards and the highest paid report in Google VRP history of $605,000!

In our continued effort to ensure the security of Google device users, we have expanded the scope of Android and Google Devices in our program and are now incentivizing vulnerability research in the latest versions of Google Nest and Fitbit! For more information on the latest program version and qualifying vulnerability reports, please visit our public rules page.

We are also excited to share that the invite-only Android Chipset Security Reward Program (ACSRP) - a private vulnerability reward program offered by Google in collaboration with manufacturers of Android chipsets - rewarded $486,000 in 2022 and received over 700 valid security reports.

We would like to give a special shoutout to some of our top researchers, whose continued hard work helps to keep Android safe and secure:

  • Submitting an impressive 200+ vulnerabilities to the Android VRP this year, Aman Pandey of Bugsmirror remains one of our program’s top researchers. Since submitting their first report in 2019, Aman has reported more than 500 vulnerabilities to the program. Their hard work helps ensure the safety of our users; a huge thank you for all of their hard work!
  • Zinuo Han of OPPO Amber Security Lab quickly rose through our program’s ranks, becoming one of our top researchers. In the last year they have identified 150 valid vulnerabilities in Android.
  • Finding yet another critical exploit chain, gzobqq submitted our highest valued exploit to date.
  • Yu-Cheng Lin (林禹成) (@AndroBugs) remains one of our top researchers submitting just under 100 reports this year.

Chrome

Chrome VRP had another unparalleled year, receiving 470 valid and unique security bug reports, resulting in a total of $4 million of VRP rewards. Of the $4M, $3.5 million was rewarded to researchers for 363 reports of security bugs in Chrome Browser and nearly $500,000 was rewarded for 110 reports of security bugs in ChromeOS.

This year, Chrome VRP re-evaluated and refactored the Chrome VRP reward amounts to increase the reward amounts for the most exploitable and harmful classes and types of security bugs, as well as added a new category for memory corruption bugs in highly privileged processes, such as the GPU and network process, to incentivize research in these critical areas. The Chrome VRP increased the fuzzer bonuses for reports from VRP-submitted fuzzers running on the Google ClusterFuzz infrastructure as part of the Chrome Fuzzing program. A new bisect bonus was introduced for bisections performed as part of the bug report submission, which helps the security team with our triage and bug reproduction.

2023 will be the year of experimentation in the Chrome VRP! Please keep a lookout for announcements of experiments and potential bonus opportunities for Chrome Browser and ChromeOS security bugs.

The entire Chrome team sincerely appreciates the contributions of all our researchers in 2022 who helped keep Chrome Browser, ChromeOS, and all the browsers and software based on Chromium secure for billions of users across the globe.

In addition to posting about our Top 0-22 Researchers in 2022, Chrome VRP would like to specifically acknowledge some specific researcher achievements made in 2022:

  • Rory McNamara, a six-year participant in Chrome VRP as a ChromeOS researcher, became the highest rewarded researcher of all time in the Chrome VRP. Most impressive is that Rory has achieved this in a total of only 40 security bug submissions, demonstrating just how impactful his findings have been - from ChromeOS persistent root command execution, resulting in a $75,000 reward back in 2018, to his many reports of root privilege escalation both with and without persistence. Rory was also kind enough to speak at the Chrome Security Summit in 2022 to share his experiences participating in the Chrome VRP over the years. Thank you, Rory!
  • SeongHwan Park (SeHwa), a participant in the Chrome VRP since mid-2021, has been an amazing contributor of ANGLE / GPU security bug reports in 2022 with 11 solid quality reports of GPU bugs earning them a spot on Chrome VRP 2022 top researchers list. Thank you, SeHwa!

Securing Open Source

Recognizing the fact that Google is one of the largest contributors and users of open source in the world, in August 2022 we launched OSS VRP to reward vulnerabilities in Google's open source projects - covering supply chain issues of our packages, and vulnerabilities that may occur in end products using our OSS. Since then, over 100 bughunters have participated in the program and were rewarded over $110,000.

Sharing Knowledge

We’re pleased to announce that in 2022, we’ve made the learning opportunities for bug hunters available at our Bug Hunter University (BHU) more diverse and accessible. In addition to our existing collections of articles, which support improving your reports and avoiding invalid reports, we’ve made more than 20 instructional videos available. Clocking in at around 10 minutes each, these videos cover the most relevant learning topics and trends we’ve observed over the past years.

To make this happen, we teamed up with some of your favorite and best-known security researchers from around the globe, including LiveOverflow, PwnFunction, stacksmashing, InsiderPhD, PinkDraconian, and many more!

If you’re tired of reading our articles, or simply curious and looking for an alternative way to expand your bug hunting skills, these videos are for you. Check out our overview, or hop right in to the BHU YouTube playlist. Happy watching & learning!


Google Play

2022 was a year of change for the Google Play Security Reward Program. In May we onboarded both new teammates and some old friends to triage and lead GPSRP. We also sponsored NahamCon ‘22, BountyCon in Singapore, and NahamCon Europe’s online event. In 2023 we hope to continue to grow the program with new bug hunters and partner on more events focused on Android & Google Play apps.

Research Grants

In 2022 we continued our Vulnerability Research Grant program with success. We’ve awarded more than $250,000 in grants to over 170 security researchers. Last year we also piloted collaboration double VRP rewards for selected grants and are looking forward to expanding it even more in 2023.

If you are a Google VRP researcher and want to be considered for a Vulnerability Research Grant, make sure you opted in on your bughunters profile.

Looking Forward

Without our incredible security researchers we wouldn’t be here sharing this amazing news today. Thank you again for your continued hard work!

Also, in case you haven’t seen Hacking Google yet, make sure to check out the “Bug Hunters” episode, featuring some of our very own super talented bug hunters.

Thank you again for helping to make Google, the Internet, and our users more safe and secure! Follow us on @GoogleVRP for other news and updates.

Thank you to Adam Bacchus, Dirk Göhmann, Eduardo Vela, Sarah Jacobus, Amy Ressler, Martin Straka, Jan Keller, Tony Mendez, Rishika Hooda

Hardening Firmware Across the Android Ecosystem

Posted by Roger Piqueras Jover, Ivan Lozano, Sudhi Herle, and Stephan Somogyi, Android Team

A modern Android powered smartphone is a complex hardware device: Android OS runs on a multi-core CPU - also called an Application Processor (AP). And the AP is one of many such processors of a System On Chip (SoC). Other processors on the SoC perform various specialized tasks — such as security functions, image & video processing, and most importantly cellular communications. The processor performing cellular communications is often referred to as the baseband. For the purposes of this blog, we refer to the software that runs on all these other processors as “Firmware”.

Securing the Android Platform requires going beyond the confines of the Application Processor (AP). Android’s defense-in-depth strategy also applies to the firmware running on bare-metal environments in these microcontrollers, as they are a critical part of the attack surface of a device.

A popular attack vector within the security research community

As the security of the Android Platform has been steadily improved, some security researchers have shifted their focus towards other parts of the software stack, including firmware. Over the last decade there have been numerous publications, talks, Pwn2Own contest winners, and CVEs targeting exploitation of vulnerabilities in firmware running in these secondary processors. Bugs remotely exploitable over the air (eg. WiFi and cellular baseband bugs) are of particular concern and, therefore, are popular within the security research community. These types of bugs even have their own categorization in well known 3rd party exploit marketplaces.

Regardless of whether it is remote code execution within the WiFi SoC or within the cellular baseband, a common and resonating theme has been the consistent lack of exploit mitigations in firmware. Conveniently, Android has significant experience in enabling exploit mitigations across critical attack surfaces.

Applying years worth of lessons learned in systems hardening

Over the last few years, we have successfully enabled compiler-based mitigations in Android — on the AP — which add additional layers of defense across the platform, making it harder to build reproducible exploits and to prevent certain types of bugs from becoming vulnerabilities. Building on top of these successes and lessons learned, we’re applying the same principles to hardening the security of firmware that runs outside of Android per se, directly on the bare-metal hardware.

In particular, we are working with our ecosystem partners in several areas aimed at hardening the security of firmware that interacts with Android:

Bare-metal support

Compiler-based sanitizers have no runtime requirements in trapping mode, which provides a meaningful layer of protection we want: it causes the program to abort execution when detecting undefined behavior. As a result, memory corruption vulnerabilities that would otherwise be exploitable are now stopped entirely. To aid developers in testing, troubleshooting, and generating bug reports on debug builds, both minimal and full diagnostics modes can be enabled, which require defining and linking the requisite runtime handlers.

Most Control Flow Integrity (CFI) schemes also work for bare-metal targets in trapping mode. LLVM’s1 CFI across shared libraries scheme (cross-DSO) is the exception as it requires a runtime to be defined for the target. Shadow Call Stack, an AArch64-only feature, has a runtime component which initializes the shadow stack. LLVM does not provide this runtime for any target, so bare-metal users would need to define that runtime to use it.

The challenge

Enabling exploit mitigations in firmware running on bare metal targets is no easy feat. While the AP (Application Processor) hosts a powerful operating system (Linux) with comparatively abundant CPU and memory resources, bare metal targets are often severely resource-constrained, and are tuned to run a very specific set of functions. Any perturbation in compute and/or memory consumption introduced by enabling, for example, compiler-based sanitizers, could have a significant impact in functionality, performance, and stability.

Therefore, it is critical to optimize how and where exploit mitigations are turned on. The goal is to maximize impact — harden the most exposed attack surface — while minimizing any performance/stability impact. For example, in the case of the cellular baseband, we recommend focusing on code and libraries responsible for parsing messages delivered over the air (particularly for pre-authentication protocols such as RRC and NAS, which are the most exposed attack surface), libraries encoding/decoding complex formats (for example ASN.1), and libraries implementing IMS (IP Multimedia System) functionality, or parsing SMS and/or MMS.

Fuzzing and Vulnerability Rewards Program

Enabling exploit mitigations and compiler-based sanitizers are excellent techniques to minimize the chances of unknown bugs becoming exploitable. However, it is also important to continuously look for, find, and patch bugs.

Fuzzing continues to be a highly efficient method to find impactful bugs. It’s also been proven to be effective for signaling larger design issues in code. Our team partners closely with Android teams working on fuzzing and security assessments to leverage their expertise and tools with bare metal targets.

This collaboration also allowed us to scale fuzzing activities across Google by deploying central infrastructure that allows fuzzers to run in perpetuity. This is a high-value approach known as continuous fuzzing.

In parallel, we also accept and reward external contributions via our Vulnerability Rewards Program. Along with the launch of Android 13, we updated the severity guidelines to further highlight remotely exploitable bugs in connectivity firmware. We look forward to the contributions from the security research community to help us find and patch bugs in bare metal targets.

On the horizon

In Android 12 we announced support for Rust in the Android platform, and Android 13 is the first release with a majority of new code written in a memory safe language. We see a lot of potential in also leveraging memory-safe languages for bare metal targets, particularly for high risk and exposed attack surface.

Hardening firmware running on bare metal to materially increase the level of protection - across more surfaces in Android - is one of the priorities of Android Security. Moving forward, our goal is to expand the use of these mitigation technologies for more bare metal targets, and we strongly encourage our partners to do the same. We stand ready to assist our ecosystem partners to harden bare metal firmware.

Special thanks to our colleagues who contributed to this blog post and our firmware security hardening efforts: Diana Baker, Farzan Karimi, Jeffrey Vander Stoep, Kevin Deus, Eugene Rodionov, Pirama Arumuga Nainar, Sami Tolvanen, Stephen Hines, Xuan Xing, Yomna Nasser.

Notes

  1. LLVM - is a compiler framework used by multiple programming languages ↩

Sustaining Digital Certificate Security – TrustCor Certificate Distrust

Posted by Chrome Root Program, Chrome Security Team

Note: This post is a follow-up to discussions carried out on the Mozilla “Dev Security Policy” Web PKI public discussion forum Google Group in December 2022. Google Chrome communicated its distrust of TrustCor in the public forum on December 15, 2022.

The Chrome Security Team prioritizes the security and privacy of Chrome’s users, and we are unwilling to compromise on these values.

Google includes or removes CA certificates within the Chrome Root Store as it deems appropriate for user safety in accordance with our policies. The selection and ongoing inclusion of CA certificates is done to enhance the security of Chrome and promote interoperability.

Behavior that attempts to degrade or subvert security and privacy on the web is incompatible with organizations whose CA certificates are included in the Chrome Root Store. Due to a loss of confidence in its ability to uphold these fundamental principles and to protect and safeguard Chrome’s users, certificates issued by TrustCor Systems will no longer be recognized as trusted by:

  • Chrome versions 111 (landing in Beta approximately February 9, 2023 and Stable approximately March 7, 2023) and greater; and
  • Older versions of Chrome capable of receiving Component Updates after Chrome 111’s Stable release date.

This change was first communicated in the Mozilla “Dev Security Policy” Web PKI public discussion forum Google Group on December 15, 2022.

This change will be implemented via our existing mechanisms to respond to CA incidents via:

  • An integrated certificate blocklist, and
  • Removal of certificates included in the Chrome Root Store.

Beginning approximately March 7, 2023, navigations to websites that use a certificate that chains to one of the roots detailed below will be considered insecure and result in a full page certificate error interstitial.

Affected Certificates (SHA-256 fingerprint):

This change will be integrated into the Chromium open-source project as part of a default build. Questions about the expected behavior in specific Chromium-based browsers should be directed to their maintainers.

This change will be incorporated as part of the regular Chrome release process to ensure sufficient time for testing and replacing affected certificates by website operators. Information about release timetables and milestones is available at https://chromiumdash.appspot.com/schedule.

Beginning approximately February 9, 2023, website operators can preview these changes in Chrome 111 Beta. Website operators will also be able to preview the change sooner, using our Dev and Canary channels. The majority of users will not encounter behavior changes until the release of Chrome 111 to the Stable channel, approximately March 7, 2023.

Summarizing security response of other Google products:

  • Android has removed TrustCor’s root CA certificates from the set of platform trusted certificates shipping with future operating system versions. Existing versions of Android will distrust TrustCor’s root CA certificates on a similar timeline as described above for Chrome.
  • Gmail is finalizing its action plan and updates will be made available in the future.

Supporting the Use of Rust in the Chromium Project

Posted by Dana Jansens (she/her), Chrome Security Team

We are pleased to announce that moving forward, the Chromium project is going to support the use of third-party Rust libraries from C++ in Chromium. To do so, we are now actively pursuing adding a production Rust toolchain to our build system. This will enable us to include Rust code in the Chrome binary within the next year. We’re starting slow and setting clear expectations on what libraries we will consider once we’re ready.

In this blog post, we will discuss how we arrived at the decision to support third-party Rust libraries at this time, and not broader usage of Rust in Chromium.

Why We Chose to Bring Rust into Chromium

Our goal in bringing Rust into Chromium is to provide a simpler (no IPC) and safer (less complex C++ overall, no memory safety bugs in a sandbox either) way to satisfy the rule of two, in order to speed up development (less code to write, less design docs, less security review) and improve the security (increasing the number of lines of code without memory safety bugs, decreasing the bug density of code) of Chrome. And we believe that we can use third-party Rust libraries to work toward this goal.

Rust was developed by Mozilla specifically for use in writing a browser, so it’s very fitting that Chromium would finally begin to rely on this technology too. Thank you Mozilla for your huge contribution to the systems software industry. Rust has been an incredible proof that we should be able to expect a language to provide safety while also being performant.

We know that C++ and Rust can play together nicely, through tools like cxx, autocxx bindgen, cbindgen, diplomat, and (experimental) crubit. However there are also limitations. We can expect that the shape of these limitations will change in time through new or improved tools, but the decisions and descriptions here are based on the current state of technology.

How Chromium Will Support the Use of Rust

The Chrome Security team has been investing time into researching how we should approach using Rust alongside our C++ code. Understanding the implications of incrementally moving to writing Rust instead of C++, even in the middle of our software stack. What the limits of safe, simple, and reliable interop might be.

Based on our research, we landed on two outcomes for Chromium.

  1. We will support interop in only a single direction, from C++ to Rust, for now. Chromium is written in C++, and the majority of stack frames are in C++ code, right from main() until exit(), which is why we chose this direction. By limiting interop to a single direction, we control the shape of the dependency tree. Rust can not depend on C++ so it cannot know about C++ types and functions, except through dependency injection. In this way, Rust can not land in arbitrary C++ code, only in functions passed through the API from C++.
  2. We will only support third-party libraries for now. Third-party libraries are written as standalone components, they don’t hold implicit knowledge about the implementation of Chromium. This means they have APIs that are simpler and focused on their single task. Or, put another way, they typically have a narrow interface, without complex pointer graphs and shared ownership. We will be reviewing libraries that we bring in for C++ use to ensure they fit this expectation.

The Interop Between Rust and C++ in Chromium

We have observed that most successful C/C++ and Rust interop stories to date have been built around interop through narrow APIs (e.g. libraries for QUIC or bluetooth, Linux drivers) or through clearly isolated components (e.g. IDLs, IPCs). Chrome is built on foundational but really wide C++ APIs, such as the //content/public layer. We examined what it would mean for us to build Rust components against these types of APIs. At a high level what we found was that because C++ and Rust play by different rules, things can go sideways very easily.

For example, Rust guarantees temporal memory safety with static analysis that relies on two inputs: lifetimes (inferred or explicitly written) and exclusive mutability. The latter is incompatible with how the majority of Chromium’s C++ is written. We hold redundant mutable pointers throughout the system, and pointers that provide multiple paths to reach mutable pointers. We have cyclical mutable data structures. This is especially true in our browser process, which contains a giant interconnected system of (mutable) pointers. If these C++ pointers were also used as Rust references in a complex or long-lived way, it would require our C++ authors to understand the aliasing rules of Rust and prevent the possibility of violating them, such as by:

  • Returning the same mutable pointer from a function twice, where the first may still be held.
  • Passing overlapping pointers where one is mutable into Rust, in a way that they may be held as references at the same time.
  • Mutating state that is visible to Rust through a shared or mutable reference.

Without interop tools providing support via the compiler and the type system, developers would need to understand all of the assumptions being made by Rust compiler, in order to not violate them from C++. In this framing, C++ is much like unsafe Rust. And while unsafe Rust is very costly to a project, its cost is managed by keeping it encapsulated and to the minimum possible. In the same way, the full complexity of C++ would need to be encapsulated from safe Rust. Narrow APIs designed for interop can provide similar encapsulation, and we hope that interop tools can provide encapsulation in other ways that allow wider APIs between the languages.

The high-level summary is that without additional interop tooling support:

  • Passing pointers/references across languages is risky.
  • Narrow interfaces between the languages is critical to make it feasible to write code correctly.

Any cross-language interop between arbitrary code introduces difficulties where concepts in one language are not found in the other. For Rust calling into C++, support for language features like templates or inheritance can be difficult for a binding generator to support. For C++ calling into Rust, proc macros, and traits are examples that provide similar challenges. At times, the impedance mismatch represents intentional design choices made for either language, however they also imply limits on FFI (interop) between the languages. We rely on interop tools to model the ideas of each language in a way that makes sense to the other, or to disallow them.

Accessing the Rust Ecosystem from Chromium

These challenges present an opportunity, both to make interop easier and more seamless, but also to get access to a wider range of libraries from either language. Google is investing in Crubit, an experiment in how to increase the fidelity of interop between C++ and Rust and express or encapsulate the requirements of each language to the other.

The Rust ecosystem is incredibly important, especially to a security-focused open source project like Chromium. The ecosystem is enormous (96k+ crates on crates.io) and growing, with investment from the systems development industry at large, including Google. Chrome relies heavily on third-party code, and we need to keep up with where that third-party investment is happening. It is critical that we build out support for including Rust into the Chromium project.

We will be following this strategy to establish norms, and to maintain a level of API review through the third-party process, while we look to the future of interop support pushing the boundaries of what is possible and reasonable to do between Rust and C++.


Some Other Related Content

Memory unsafety is an industry-wide problem, and making use of Rust is one part of a strategy to move the needle in this area. Recently, Android and Apple have each published a great blog post on the subject if you’re interested in learning more. With Chrome’s millions of lines of C++, we’re still working hard to improve the safety of our C++ too, through projects such as MiraclePtr.

Expanding the App Defense Alliance

Posted by Brooke Davis, Android Security and Privacy Team

The App Defense Alliance launched in 2019 with a mission to protect Android users from bad apps through shared intelligence and coordinated detection between alliance partners. Earlier this year, the App Defense Alliance expanded to include new initiatives outside of malware detection and is now the home for several industry-led collaborations including Malware Mitigation, MASA (Mobile App Security Assessment) & CASA (Cloud App Security Assessment). With a new dedicated landing page at appdefensealliance.dev, the ADA has an expanded mission to protect Android users by removing threats while improving app quality across the ecosystem. Let’s walk through some of the latest program updates from the past year, including the addition of new ADA members.

Malware Mitigation

Together, with the founding ADA members - Google, ESET, Lookout, and Zimperium, the alliance has been able to reduce the risk of app-based malware and better protect Android users. These partners have access to mobile apps as they are being submitted to the Google Play Store and scan thousands of apps daily, acting as another, vital set of eyes prior to an app going live on Play. Knowledge sharing and industry collaboration are important aspects in securing the world from attacks and that’s why we’re continuing to invest in the program.


New ADA Members

We’re excited to see the ADA expand with the additions of McAfee and Trend Micro. Both McAfee and Trend Micro are leaders in the antivirus space and we look forward to their contributions to the program.

Mobile App Security Assessment (MASA)

With consumers spending four to five hours per day in mobile apps, ensuring the safety of these services is more important than ever. According to Data.ai, the pandemic accelerated existing mobile habits - with app categories like finance growing 25% YoY and users spending over 100 billion hours in shopping apps.

That’s why the ADA introduced MASA (Mobile App Security Assessment), which allows developers to have their apps independently validated against the Mobile Application Security Verification Standard (MASVS standard) under the OWASP Mobile Application Security project. The project’s mission is to “Define the industry standard for mobile application security,” and has been used by both public and private sector organizations as a form of industry best practices when it comes to mobile application security. Developers can work directly with an ADA Authorized Lab to have their apps evaluated against a set of MASVS L1 requirements. Once successful, the app’s validation is listed in the recently launched App Validation Directory, which provides users a single place to view all app validations. The Directory also allows users to access more assessment details including validation date, test lab, and a report showing all test steps and requirements. The Directory will be updated over time with new features and search functionality to make it more user friendly.

The Google Play Store is the first commercial app store to recognize and display a badge for any app that has completed an independent security review through ADA MASA. The badge is displayed within an app’s respective Data Safety section.

This MASA program launched in beta earlier this year and is now available for all developers. We’ve seen strong early developer interest with leading apps across a diverse set of categories completing validation including Roblox, Uber, PayPal, Threema, Google Photos, YouTube and many more. On average, developers have completed validation within a month and resolved two outstanding issues identified by a security lab.

To learn more about the program and to help developers get started, there’s a Play Academy course dedicated to independent security review. Check out the interactive guidance on the Academy for App Success and get started today!

Cloud App Security Assessment (CASA)

As the industry continues to evolve and software connects more systems through complex cloud-to-cloud integrations, focusing on the security of cloud applications and their supporting infrastructure becomes increasingly critical. CASA (Cloud App Security Assessment) leverages the work set forth in OWASP’s Application Security Verification Standard ASVS to provide a consistent set of requirements to harden security for any application. The CASA framework provides multiple assurance levels in which low-risk cloud applications can be evaluated using either a self assessment or automated scan. For applications which present higher risk (such as a large user base, recent security breach, or processes highly sensitive data), an Authorized Lab may perform an assessment.

Further, the CASA accelerator provides developers with a workflow that minimizes the required checks depending on the developer's current valid certifications. The CASA checks have been mapped to 10 certifications and frameworks which eliminate redundant testing while lowering the cost of the assessment. Google is continuing to invest in this space with plans to use ASVS more proactively with the developer community next year.

It's been amazing to see the ADA grow this year and we are excited for the continued progress and expansion around the alliance’s mission.

Trust in transparency: Private Compute Core

Posted by Dave Kleidermacher, Dianne Hackborn, and Eugenio Marchiori

We care deeply about privacy. We also know that trust is built by transparency. This blog, and the technical paper reference within, is an example of that commitment: we describe an important new Android privacy infrastructure called Private Compute Core (PCC).

Some of our most exciting machine learning features use continuous sensing data — information from the microphone, camera, and screen. These features keep you safe, help you communicate, and facilitate stronger connections with people you care about. To unlock this new generation of innovative concepts, we built a specialized sandbox to privately process and protect this data.

Android Private Compute Core

PCC is a secure, isolated data processing environment inside of the Android operating system that gives you control of the data inside, such as deciding if, how, and when it is shared with others. This way, PCC can enable features like Live Translate without sharing continuous sensing data with service providers, including Google.

PCC is part of Protected Computing, a toolkit of technologies that transform how, when, and where data is processed to technically ensure its privacy and safety. For example, by employing cloud enclaves, edge processing, or end-to-end encryption we ensure sensitive data remains in exclusive control of the user.

How Private Compute Core works

PCC is designed to enable innovative features while keeping the data needed for them confidential from other subsystems. We do this by using techniques such as limiting Interprocess Communications (IPC) binds and using isolated processes. These are included as part of the Android Open Source Project and controlled by publicly available surfaces, such as Android framework APIs. For features that run inside PCC, continuous sensing data is processed safely and seamlessly while keeping it confidential.

To stay useful, any machine learning feature has to get better over time. To keep the models that power PCC features up to date, while still keeping the data private, we leverage federated learning and analytics. Network calls to improve the performance of these models can be monitored using Private Compute Services.

Let us show you our work

The publicly-verifiable architectures in PCC demonstrate how we strive to deliver confidentiality and control, and do it in a way that is verifiable and visible to users. In addition to this blog, we provide this transparency through public documentation and open-source code — we hope you'll have a look below.

To explain in even more detail, we’ve published a technical whitepaper for researchers and interested members of the community. In it, we describe data protections in-depth, the processes and mechanisms we’ve built, and include diagrams of the privacy structures for continuous sensing features.

Private Compute Services was recently open-sourced as well, and we invite our Android community to inspect the code that controls the data management and egress policies. We hope you'll examine and report back on PCC's implementation, so that our own documentation is not the only source of analysis.

Our commitment to transparency

Being transparent and engaged with users, developers, researchers, and technologists around the world is part of what makes Android special and, we think, more trustworthy. The paradigm of distributed trust, where credibility is built up from verification by multiple trusted sources, continues to extend this core value. Open sourcing the mechanisms for data protection and processes is one step towards making privacy verifiable. The next step is verification by the community — and we hope you'll join in.

We'll continue sharing our progress and look forward to hearing feedback from our users and community on the evolution of Private Compute Core and data privacy at Google.