Q3 2019 Summary from Chrome Security
Andrew R. Whalley
Greetings!
With the equinox behind us, it's time for an update on what the Chrome security team has been up to in the third quarter of 2019.
The Chrome Safe Browsing team launched Stricter Download Protections for Advanced Protection users in Chrome and significantly reduce users’ exposure to potentially risky downloads.
In Q3, Safe Browsing also brought Google password protection to signed in, non-sync users. This project is code complete, and the team plans to roll it out in Chrome 79.
Enamel, the Security UX team, have been looking at mixed content: http:// subresources on https:// pages. Mixed content presents a confusing UX and a risk to user security and privacy. After a long-running data-gathering experiment on pre-stable channels, the Enamel team publicized plans to start gradually blocking mixed content. In Chrome 79, the team plans to relocate the setting to bypass mixed content blocking from a shield icon in the omnibox to Site Settings. In Chrome 80, we will start auto-upgrading mixed audio and video to https://, blocking resources if they fail to auto-upgrade. Chrome 80 will also introduce a “Not Secure” omnibox chip for mixed images, which we plan to start auto-upgrading in a future version of Chrome.
Furthering our quest to improve the quality of HTTPS deployments, we announced a new UI plan for the upcoming legacy TLS deprecation in early 2020.
In Q3, Enamel also made improvements to our lookalike domain warning, with clearer strings and new heuristics for detecting spoofing attacks. We also added additional signals in our Suspicious Site Reporter extension for power users to identify suspicious sites that they can report to Safe Browsing for scanning. In Chrome 77, we relocated the Extended Validation certificate UI to Page Info; we presented the user research that inspired this change at USENIX Security 2019.
The Platform Security team continues to help improve the memory safety of the PDFium code base, and have finished removing all bare new/delete pairs, and ad-hoc refcounting. We continued to push for greater memory safety on a number of fronts, and are busy working on plans for the rest of the year and 2020. Q3 saw a number of projects enter trials on Beta and Stable, including the V2 sandbox for GPU process and network service sandbox on macOS, and Code Integrity Guard on Windows. Look out for news of their launch in next quarter's update!
The XSS Auditor, which attempted to detect and prevent reflected XSS attacks, was removed in Chrome 78. It had a number of issues, and in the end the cons outweighed the pros.
The Bugs-- team added FuzzedDataProvider (FDP) as part of Clang, making it simple to write fuzz targets that require multiple inputs with just a single header file include. We refactored ClusterFuzz code to make it easier to add new fuzzing engines and migrated libFuzzer to use this new interface. We rewrote the ClusterFuzz reproduce tool, which is now part of main ClusterFuzz GitHub repo. On the OSS front, we launched new features in OSS-Fuzz - Golang support, X86 config support, FDP support, and OSS-Fuzz Badges. We also did fuzzer strategy weight adjustments based on multi-armed bandit experiments. Jonathan Metzman presented at Black Hat (USA) on structure aware fuzzing.
The Open Web Platform Security team have been working on Trusted Types, the Origin Trial for which is about to finish. We are making a number of changes to the feature, mainly to aid deployment and debugging of TT deployments, as well as some overall simplifications. We expect this work to finish in early Q4, and to launch in the same quarter.
The Site Isolation team reached two more important milestones in Q3. First, we enabled Site Isolation for password sites on Chrome for Android (on devices with at least 2GB of memory), bringing Spectre mitigations to mobile devices! Second, we added enough compromised renderer protections on Chrome for Desktop to include cross-site data disclosure to the Chrome VRP! We're very excited about the new protections, and we continue to improve the defenses on both Android and Desktop. Separately, we presented our USENIX Security paper in August and launched OOPIF-based PDF support, clearing the way to remove BrowserPlugin.
In the Web PKI space, the government of Kazakhstan recently created a Root CA and with local ISPs engaged in a campaign to encourage all KZ citizens to install and trust the CA. Ripe Atlas detected this CA conducting a man-in-the-middle on social media. Chrome blocked this certificate to prevent it from being used for MITMing Chrome users. In conjunction with several other major browsers, we made a joint PR statement against this type of intentional exploitation of users. Following this incident, we began working on a long-term solution to handling MITM CAs in Chrome.
In hacker philanthropy news, in July we increased the amounts awarded to security researchers who submit security bugs to us under the Chrome Vulnerability Reward Program. The update aligned both categories and amounts with the areas we'd like researchers to focus on. This generated some good press coverage which should help spread the word about the Chrome VRP. Tell your friends, and submit your Chrome security bugs here and they'll be considered for a reward when they're fixed!
In Chrome security generally we've been working to address an issue called the “patch gap”, where security bug fixes are posted in our open-source code repository but then take some time before they are released as a Chrome stable update. During that time, adversaries can use those fixes as evidence of vulnerabilities in the current version of Chrome. To reduce this problem, we’ve been merging more security fixes directly to stable, and we’re now always making a security respin mid-way through the six-week development cycle. This has reduced the median patch gap from ~33 days in Chrome 76 to ~19 days in Chrome 77. This is still too long, and we’re continuing to explore further solutions.
Cheers,
Andrew, on behalf of the Chrome security team
(You can see our previous updates here: https://dev.chromium.org/Home/chromium-security/quarterly-updates)