With apologies to those still waiting patiently for our Q1 update, here instead is a look back at what the Chrome Security teams have been up to in the first half of 2021.
Chrome is hiring, including for security positions! See g.co/chrome/hiring. In particular we're looking for a lead security product manager to work with the teams doing all the great things in this update, and more across the Chrome Trust and Safety organisation.
The first half of 2021 is trending toward record-setting totals for the Chrome Vulnerability Reward Program (VRP) with the security researcher community awarded $1.7M for reporting close to 200 unique, valid security bugs. Of these reward-eligible reports, 84 were reports for Critical and High severity issues that impacted stable channel users. The Chrome VRP continues to be a vital part of our security ecosystem and we greatly appreciate the efforts of the Chrome VRP researcher community to help keep Chrome users more secure!
In a collaborative effort led by the Google VRP, the new Google BugHunters site was launched. Chrome bugs can be reported via that site, as well as at crbug.com/new using the Security Bug template as before.
In collaboration with the other VRP programs across Google, bonuses were paid out to VRP researchers impacted by recent payment delays. We are additionally working on ways to proactively decrease future delays, and improve the efficiency and processes of the program.
In Q1 the Safe Browsing team grew the Enhanced Safe Browsing population by more than 400% through in-product integrations with the security interstitial pages and Safety Check. We also started using machine learning models to protect users who have real-time Safe Browsing lookups against phishing attacks which, along with heuristic-based enforcement, allowed us to decrease our phishing false negatives by up to 20%.
We designed improvements to our client-side phishing detection subsystem, which will allow us to innovate faster in that area in the coming quarters.
In Q2 we rolled out a new set of protections for Enhanced Safe Browsing users in Chrome 91: Improved download protection by offering scanning of suspicious downloads, and better protection against untrusted extensions. We continued to see a phenomenal growth in the number of users who opt in to Enhanced Safe Browsing to get Chrome’s highest level of security.
We helped land improvements to the client-side phishing detection subsystem in Chrome 92 which made image-based phishing classification up to 50 times faster. And we landed improvements to the Chrome Cleanup Tool to remove new families of unwanted software from the users’ machines.
In Chrome 90, we launched a milestone for a secure web: Chrome’s omnibox now defaults to HTTPS when users don’t specify a scheme. We later announced a set of changes to prepare the web for an HTTPS-first future. We’re implementing HTTPS-First Mode as an option for Chrome 94, a setting that will cause Chrome to automatically upgrade navigations to HTTPS, and show a full-page warning before falling back to HTTP. We’ll also be experimenting with a new security indicator icon for HTTPS pages in Chrome 93, inspired by our research showing that many users don’t understand the security assurances of the padlock icon. Finally, we announced a set of guiding principles for protecting and informing users on the slice of the web that is still HTTP.
To try out HTTPS-First Mode in Chrome Canary, toggle “Always use secure connections” in chrome://settings/security. You can also preview our new HTTPS security indicator by enabling “Omnibox Updated connection security indicators” in chrome://flags and then re-launching Chrome.
In June, Chrome passed a huge milestone in the history of Certificate Transparency. The last certificates issued before Chrome required CT logging have now expired. That eliminates a hole where a malicious or compromised CA key could backdate a cert to avoid logging it. Congratulations to all who've worked on CT over the years, and those who continue to keep the ecosystem thriving.
To further strengthen the Certificate Transparency ecosystem, we launched the first phase of SCT auditing, which helps verify that CT logs are behaving honestly, and designed and began implementing subsequent phases to improve coverage and reliability. In Chrome 94 we’ll launch a change to distribute CT log information to clients faster and more reliably, which will help unblock CT enforcement on Chrome for Android.
We’ve made progress on under-the-hood improvements to certificates and TLS. We proposed a set of changes in the CA/Browser Forum to better specify how website (and other) certificates should be structured, and we helped make improvements such as tightening validation procedures for wildcard certificates and sunsetting an unvalidated certificate field. We distrusted the Camerfirma CA, initially planned for Chrome 90 but later delayed until Chrome 91 due to the exceptional circumstances of some Covid-19 related government websites being slow to migrate.
On the TLS front, we launched a performance improvement to the latest version of TLS — zero round-trip handshakes in TLS 1.3 — to Canary and Dev. We announced and implemented the removal of the obsolete 3DES cipher. Finally, a new privacy feature for TLS, Encrypted Client Hello, is now implemented in our TLS library, with integration into Chrome ongoing.
The Open Web Platform Security team implemented and specced a first version of the Sanitizer API, that will help developers avoid pesky XSS bugs. In combination with Trusted Types that we released last year, it will help websites defend against XSS attacks.
CORS-RFC1918 got renamed to Private Network Access. We are ready to ship restrictions on accessing resources from private networks from public HTTP pages in Chrome 94: public HTTP pages will no longer be able to request resources from private networks. We will have a reverse Origin Trial in place until our preferred workaround (WebTransport) has shipped. We are also working on the next stage of Private Network Access restrictions, where we will send a CORS preflight when a public page tries to access a private resource.
CrossOriginIsolated is really difficult to adopt for websites. We’re planning to make a few changes to help with deployment. First, we have a new version of COEP: credentialless currently undergoing an Origin Trial. It will help developers deploy COEP when they embed third-party subresources. We’re also working on anonymous iframes, to deploy COEP on pages that embed legacy 3rd party iframes. And we want to have COOP same-origin-allow-popups + COEP enable crossOriginIsolated to help with OAuth and payment flows support.
In Q1, the Security Architecture team continued work on several Site Isolation efforts: isolating sites that use COOP or OAuth on Android, metrics for protecting data with ORB, better handling of about:blank origins and tracking of content scripts, and helping with the communications for the Spectre proof-of-concept and recommendations. Additionally, Origin Agent Cluster shipped in Chrome 88, offering process isolation at an origin granularity (for performance reasons rather than security). We explored new options for memory safety and helped with the MiraclePtr experiments. Finally, we made several stability improvements, continued refactoring for SiteInstanceGroup, and helped unblock the MPArch work.
Q2 saw work improving Site Isolation protections for Origin headers (via request initiator enforcements) and extension IPCs. We started several Site Isolation related beta trials, including isolating more sites on Android and isolating extensions from each other on desktop. We started an early prototype of isolating same-site sandboxed iframes and analyzed metrics for protecting data with ORB, as well. We also contributed to several efforts to improve memory safety in Chrome, solved long-standing speculative RenderFrameHost crashes, and improved support for Origin Agent Cluster.
The Platform Security team had a busy first half of the year. We have now deployed Hardware-enforced stack protection for Windows (also known as Control-flow Enforcement Technology, CET) to most Chrome processes, on supported hardware. CET protects against control flow attacks attempting to subvert the return from a function, and we blogged about this earlier in the year.
With the returns from functions now protected by CET, we are making good headway in protecting the function calls themselves — indirect calls, or 'icalls' using CFG (Control Flow Guard). We have full CFG support for all processes behind a compile time flag 'win_enable_cfg_guards = true', so please try it, but in the meantime we are working on ironing out performance issues so we can roll it out to as many processes as possible.
The stack canary mitigation has been significantly strengthened on Linux and Chrome OS. These platforms use the zygote for launching new processes, so the secret stack canary value was the same in each process, which means the mitigation is useless once an attacker has taken over a single process. The stack canaries are now re-randomized in each process.
On macOS, we finished our complete rollout of our V2 sandbox architecture with the launch of the new GPU process sandbox. That marks the end of a nearly four-year project to eliminate the unsandboxed warm-up phase of our processes, which reduces the amount of attack surface available to a process. In addition, we enabled macOS 11’s new RIDL CPU mitigation for processes that handle untrustworthy arbitrary compute jobs (e.g. renderers).
GWP-ASAN is being field trialed on Linux, Chrome OS, and Android. GWP-ASAN is a sampling allocation tool designed to detect heap memory errors occurring in production with negligible overhead, providing allocation/deallocation/crashing stack traces for production crashes. It has already been launched on macOS and Windows but hopefully launching on new platforms should help us find and fix bugs in platform-specific code.
XFA (the form-filling part of PDF) is now using Blink's garbage collector Oilpan, protecting against use-after-frees in this code. The PDF code is also being moved from its own process that uses the legacy Pepper interface (previously used for Flash) into the same process as web content.
The work on the network service sandbox continues apace. Previously the sandbox technology being used on Windows was the same one used for the renderer (the restricted token sandbox). However, this tighter sandbox caused issues with parts of the network stack such as Windows Authentication and SSPI providers, so we are moving to an LPAC (Less Privilege App Container) sandbox which should play much nicer with enterprises.
In Q1 the extended team working on permissions was excited to start rolling out the fruits of several collaborations from last year, including the MVP of the Chrome Permission Suggestion Service (CPSS) to suppress very-unlikely-to-be-granted prompts, the automatic revocation of notification permission on abusive sites, a complete revamp of chrome://settings/content pages, and experiments for Permission Chip and one-time permission grants. CPSS reduces unwanted interruptions (number of explicit decisions which are dismissed, denied or granted) by 20 to 30%. Additionally, the less disruptive 'chip' permission UI is now live for all users for location permission requests and we’re migrating other permissions to the new pattern.
We organized a virtual workshop on next-gen permissions, identifying the core themes – modes, automation, and awareness – for future explorations, and we conducted our very first qualitative UXR study to better understand users’ mental models and expectations with permissions
We'll be back to our quarterly update cadence with news from Q3 later in the year.
Check out previous updates here: https://dev.chromium.org/Home/chromium-security/quarterly-updates