Q1 2022 Summary from Chrome Security
Andrew R. Whalley
Greetings,
The first quarter of 2022 was a busy one for Chrome Security, as you can read below. This was all in addition to our evergreen role providing security review, consulting, and support to teams across Chrome. If you'd like to be part of this fantastic team Chrome is hiring for security positions! See goo.gl/chrome/hiring for more details.
We collaborated with the Google Accounts team to launch an integration that will help users opt-in to Chrome’s Enhanced Safe Browsing protection via a similar setting for their Google account.
We’ve almost completed the implementation for the initial version of a redesigned downloads experience, and will soon run an experiment with it on Chrome 102. To stop the spread of malware through macros embedded in Microsoft Office documents, we fully launched the parsing of downloaded Office documents in Chrome 97 to identify whether they contain macros and include this information when contacting Safe Browsing to determine if they’re unsafe.
Two extension-telemetry signals are active on Chrome early channels, feeding client-side data to Safe Browsing to suss out suspicious extensions.
We also completed the launch of a new TfLite-based client-side phishing detection model on desktop platforms in Chrome 97, which showed 2.5x as many warnings as the previous model.
This quarter we launched a major new Certificate Transparency policy that removes Google from the critical path of global HTTPS certificate issuance, made possible in part by expanding our SCT Auditing efforts. This quarter also saw CT enforcement and protections coming to Android, vastly expanding the number of users protected by CT.
In preparation for the upcoming rollout of our own Chrome Root Store, we've also been developing several major policies and processes for interacting with certificate authorities, and the engineering to deliver root certificates to Chrome out-of-band. This enables Chrome to directly validate site certificates, rather than relying on each operating system’s verification.
Following last quarter's investments in better infrastructure for handling lookalike warnings appeals, and this quarter's work on safer rollout mechanisms, we are rolling out a new heuristic to detect additional lookalike domains and prepping for an intern on the project starting in Q2. Our initial implementation of TLS ECH is also now nearly code complete, with only polish work remaining.
We made great progress on our Rust-in-Chromium experiments. Rust would have security, productivity and performance benefits over C++, but we don’t yet know if we can ergonomically mix it with C++ in Chromium. This quarter, we landed a Rust JSON parser, achieving some compile-time safety while wrapping existing C++ APIs. We also landed support for a C++ -> Rust bindings generator called autocxx. In the next quarter we’ll be using that, plus another tool called crubit, to build some ambitious demos.
Work continues on sandboxing the network service across Windows, Android, and Linux/CrOS. We are making good progress on brokering or servicifying the numerous network stack subsystems that do not work within the confines of a sandbox. On Windows, we also successfully landed CFG and investigated sandbox improvements. On Mac, we experimented with Apéritif, but hit roll-out issues on older macOS versions
We’re on track for a new attempt at preflight warnings for Private Network Access requests in Chrome 102. IoT developers reported that Web Transport was insufficient as the only workaround to the PNA secure context restriction, so we’re looking at a permission-based alternative and are seeking feedback on it. The initial attempt was rolled back due to various bugs, in particular one affecting partially-cached range requests.
We created a specification for anonymous iframe and are nearing code completion. Origin Trial is expected for Chrome 106. This resolves a common difficulty: embedding arbitrary 3rd party iframes inside a crossOriginIsolated page.
We have made progress towards a decision on a new COOP policy (restrict-properties), to solve the crossOriginIsolation + popups integration.
On continued progress towards safer defaults, we shipped warnings for document.domain usage without opt-in, to prepare for eventual deprecation. And Chrome 103 saw us block sandboxed iframe from opening external applications.
In Web Platform memory safety news, we implemented a C++ dangling pointer detector. We are now working on fixing all the occurrences, and refactoring Chrome for using safer memory ownership patterns.
In Q1, the Security Architecture team continued several projects to improve Site Isolation and related defenses, including implementation work for <webview> tag Site Isolation, Site Isolation for sandboxed iframes, and the first steps towards ORB as a replacement for CORB. We worked on other security fixes for a series of use-after-free bugs involving RenderFrameHost, as well as safer ways to handle renderer process termination. We also made progress on SiteInstanceGroups, stricter enforcements for extensions and citadel checks, and Origin-Agent-Cluster by default.
Until next time,
Andrew
On behalf of Chrome Security
Justin Ferguson
> C++ APIs. We also landed support for a C++ -> Rust bindings generator called autocxx. In the next quarter
> we’ll be using that, plus another tool called crubit, to build some ambitious demos.
the CSS renderer, then it seems that Chome has had not only less
memory corruption vulnerabilities but non-memory corruption
vulnerabilities as well from Firefox. This is to say that the sort of
misnomer about safer languages turned up wrong for them yielding more
vulnerabilities, but also that the unstated that all of the other--
serious bugs (think SQL injection) turned out to be a byproduct of
Mozilla's rewrite.
IMHO, memory safety bugs are better addressed through things like
miracle pointer or shadow stacks and CFG than thinking rewriting in
whizbamo-language will magically fix the flaws-- especially given that
in a subsystem of importance where metrics are available the exact
opposite has turned out to be true.
Without argument, Rust's subsystems make great promises, but it
doesn't seem to apply to the real world where its forced interaction
with other components continue to yield not only vulnerabilities it
was intended to resolve, but also introduces equally important
vulnerabilities to which it offers no guarantees. I smell "java is
safe because of the JVM" and "java doesn't have pointers" arguments
from the early 2000s all over again.
I would hope (?) that the Chome developers are a bit smarter than
getting hoodwinked into the newest fad, especially given that the
metrics are inarguably against it. When put to practice in the real
world, you end up with more memory corruption vulnerabilities-- not
less, and the rewrite seems to cause you a host of other problems
which are equally serious.
'
> To unsubscribe from this group and stop receiving emails from it, send an email to security-dev...@chromium.org.
Alex Gaynor
I'm not aware of any metrics suggesting migration to a memory safe
language (such as Rust) produces more vulnerabilities. Can you share
that research? Indeed, all the research I've seen suggests that the
opposite is likely to be the case. I'm certainly not aware of any SQL
injection that occurred as a result of Firefox's replacement of the
CSS engine with one written in Rust.
Thanks,
Alex
All that is necessary for evil to succeed is for good people to do nothing.
Justin Ferguson
than checking mail after being a bit inebriated, so a sort of
off-topic message made it to the list.
That said, my comments are based on easily verifiable CVE listings and
when I looked I compared specifically the CSS engine because it was
the first out of the gate and at the time I looked had enough time to
merit review.
Since November of 2017, which IIRC correctly is when Servo was
released but I'm going mostly from memory and might have that slightly
incorrect, however since November of 2017, Firefox has had 2 memory
corruption vulnerabilities in its CSS engine (CVE-2021-23983 and
CVE-2020-26974), Chrome has had 1 (CVE-2020-6539) and IE had 2
(CVE-2017-0037 and CVE-2018-8460)-- taken as a metric in itself and
given the ~2 year development investment for it, it actually yielded
more memory corruption vulnerabilities than Chrome had despite the
rewrite.
Inversely, the rewrite also introduced a number of non-memory
corruption bugs (CVE-2020-26974, CVE-2020-6813, CVE-2020-26973,
CVE-2019-17022 and CVE-2021-23996). Across the same period, Chrome had
2 non-memory corruption vulnerabilities (CVE-2018-6164,
CVE-2018-6137).
The main point here being that the remaining two browsers compared,
the rewrite into a safe language managed to introduce more
vulnerabilities than the existing unsafe code in Chrome and the
rewrite itself appears to have introduced a substantial number of
non-memory corruption bugs as well.
This is at least partly unfair because if you look at the metrics for
Firefox prior to the rewrite it had a lot more memory corruption
vulnerabilities than the other two browser had in CSS and so there is
probably an accurate point to be made about code quality-- given that
webgpu is up and coming and about to be released by both browsers, and
my understanding is that Firefox is writing the implementation in Rust
and Chrome in C++, I will probably track those components across a
couple of years as well just to see how they both fare but more or
less completely unfounded "gut instinct" guess is that we'll see more
or less the same.
I'm surprised you all don't track this, whether you actually end up
with more or less real vulnerabilities reported. In fairness, my guess
would be that most of the vulnerabilities come from the interaction of
Rust interacting with native components and over some timeline when
the volume of native code approaches 0% I would expect them to go
away, but at first blush it seems doubtful to me that day will ever
come.
I think if you looked, the number of compromises coming about from SQL
injection and unsafe eval's probably far outpaces the number of
compromises coming from buffer overflows and similar memory corruption
vulnerabilities, so its a bit of a pet peeve even though that point is
far less relevant when constraining the view port solely to browsers.
Justin
Alex Gaynor
To be clear, I'm not a Chromium developer, just someone interested in
this issue.
Unfortunately I think there are methodological issues in how you are
counting vulnerabilities. Neither of the memory corruption
vulnerabilities you linked
(https://bugzilla.mozilla.org/show_bug.cgi?id=1692684 and
https://bugzilla.mozilla.org/show_bug.cgi?id=1681022) were in Rust
code, or at least the fixes for both were in C++ code. Now, it's
possible the fix is in C++ but the vulnerability was a result of the
rewrite, but I don't see any evidence for that.
Looking at the non-memory corruption vulnerabilities you shared
(https://bugzilla.mozilla.org/show_bug.cgi?id=1605814,
https://bugzilla.mozilla.org/show_bug.cgi?id=1680084,
https://bugzilla.mozilla.org/show_bug.cgi?id=1602843,
https://bugzilla.mozilla.org/show_bug.cgi?id=1701834) 2/4 of the fixes
contain updates to Rust code. However, this also fails to answer the
question of whether or not those vulnerabilities were _also_ present
in the pre-rewrite versions of the code!
Regards,
Alex
Justin Ferguson
Well I would assume that rewriting (and releasing) the CSS engine in
Rust would mean that a memory corruption vulnerability still bears
merit of mention and comparison here even though I assumed they were
likely across process boundaries or RPC-like interfaces or similar
where Rust interfaced with C++. I would call that real world usage and
it is a little delusional to say "yeah but it wasn't Rust" (well but
obviously you needed to do something you couldn't or didn't do in Rust
so it's sort of moot, right?). I mean at the end of the day you're
promising to reduce/remove the class of vulnerability and so you don't
really get to frame it in the way that you are.
It's also possible that stating that an engine rewrite is a bit more
encompassing in name than in function and so relates to code totally
untouched by the rewrite.
Looking into that very briefly, the call stack, in CVE-2021-23983 at
frame #11 you're clearly coming out of Servo and into native code and
actually you're in Rust all the way through frame #4 with frames prior
to that showing that the pointer in use that presumably causes the
error is coming straight out of rust-- so I fail to see the
distinction here. In CVE-2020-26974 you appear to have an IPC message
in one thread blowing up from a bad pointer handed to it by another
thread coming directly out of Rust. I think (if that is accurate) this
second one is probably a more sincere criticism, but I don't know how
the type-safety works across program boundaries (RPC/IPC/multi-process
boundaries/et cetera) like that, my guess is that for some of it (e.g.
multiple processes) it doesn't really.
As for the other vulnerabilities, I mostly add them to emphasize that
rewrites and new code tend to introduce new vulnerabilities. This
point earns IE some honourable mention because from memory they
switched out the CSS engine twice in native code over the same
duration (not counting the final melding with Chrome) and ended up
with the same vulnerability count.