Q1 Summary from Chrome Security

عرض 1-1 من 1 من الرسائل
Q1 Summary from Chrome Security Andrew R. Whalley 21/05/19 10:53 ص

Greetings,


Here's an update on what Chrome Security was up to in the first quarter of 2019!


The Site Isolation team finished the groundwork for Android Beta Channel field trials, and the trials are now in progress. This Android mode isolates a subset of sites that users log into, to protect site data with less overhead than isolating all sites. We also started enforcing Cross-Origin Read Blocking for extension content script requests, maintaining a temporary allowlist for affected extensions that need to migrate. We tightened compromised renderer checks for navigations, postMessage, and BroadcastChannel. We also continued cross-browser discussions about Long-Term Web Browser Mitigations for Spectre, as well as headers for isolating pages and enabling precise timers. Finally, we are close to migrating PDFs from BrowserPlugin to out-of-process iframes, allowing BrowserPlugin to be deleted.


In the last several years, the Usable Security team have put a lot of effort into improving HTTPS adoption across the web, focusing on getting top sites to migrate to HTTPS for their top-level resources. We’re now starting to turn our attention to insecure subresources, which can harm user security and privacy even if the top-level page load is secure. We are currently running an experiment on Canary, Dev, and Beta that automatically upgrades insecure subresources on secure pages to HTTPS. We also collected metrics on insecure downloads in Q1 and have started putting together a proposal to block high-risk insecure downloads initiated from secure pages.


People need to understand website identity to make good security and trust decisions, but lots of research suggests that they don’t. We summarized our own research and thinking on this topic in an Enigma 2019 talk. We open-sourced a tool that we use to help browser developers display site identity correctly. We also published a set of URL display guidelines and subsequently incorporated them into the URL standard.


The Safe Browsing team increased the coverage against malware and unwanted software downloads by changing the logic of which file types to check against Safe Browsing. We flipped the heuristic to an allow-list of known-safe file extensions, and made the rest require verification. This adds protection from both the uncommon file extensions (where attackers convince users to rename them to a common executable after scanning), and from Office document types where the incidence of malware has increased significantly.


The Chrome Cleanup Tool is now in the Chromium repository! This lets the public audit the data collected by the tool, which is a win for user privacy, and gives an example of how to sandbox a file scanner. The open source version includes a sample scanner that detects only test files, while the version shipped in Chrome will continue to depend on internal resources for a licensed engine.


The Bugs-- team has open sourced ClusterFuzz, a fuzzing infrastructure that we have been developing over the past 8 years! This army of robots has found 30,000+ bugs in Chrome and 200+ open source projects. To improve the efficiency of our cores, we have developed automated fuzzer weights management based on fuzzer quality/freshness/code changes. Additionally, we have developed several new WebGL fuzzers (some of them leverage GraphicsFuzz) and found 63 bugs. We have significantly scaled up fuzzing Chrome on Android (x86) by using Cuttlefish over GCE. Lastly, we have transitioned Chrome code coverage tools development to Chrome Infra team, see the new dash here.


The Platform Security team added some checks for basic safety to our base and other fundamental libraries, and are investigating how to do more while maintaining efficiency (run-time, run space, and object code size). We hope to continue to do more, as well as investigate how to use absl without forgoing the safety checks. We’ve been having great success with this kind of thing in PDFium as well, where we’ve found that the compiler can often optimize away these checks, and investigating where it hasn’t been able to has highlighted several pre-existing bugs. On macOS, we have re-implemented the Mojo IPC Channel under the hood to use Mach IPC, which should help reduce system resource shortage crashes. This also led to the development of two libprotobuf-mutator (LPM) fuzzers for Mach IPC servers. We’re working on auto-generating an LPM based fuzzer from Mojo API descriptions to automatically fuzz Mojo endpoints, in-process. We also continue to write LPM fuzzers for tricky-to-reach areas of the code like the disk cache. We are also investigating reducing the privilege of the network process on Windows and macOS.


Our next update will be for the first full quarter after joining Chrome Trust and Safety Looking forward to collaborating with more teams who are also working to keep our users safe!


Cheers,


Andrew on behalf of Chrome Security