What Blink means for Chrome Security
The Chromium project recently announced that we’ve forked WebKit as the Blink project <goo.gl/yF9QJ>. Amidst all the other discussion about what this means, I’d like to give my perspective on how it impacts Chrome security going forward. As always, these are my own thoughts, and don’t necessarily reflect the positions of Google, the Chromium Project, or anyone else.
So... I think it’s safe to say that the Chrome security team has taken a very active role in WebKit security over the last several years, and really led the pack in making Webkit more robust against exploits. We’ve fuzzed at previously unheard of scale <goo.gl/R718K>, paid out hundreds of thousands of dollars in bug bounties <goo.gl/PGr89>, performed extensive code auditing, fixed many hundreds of security bugs, and introduced a slew of hardening measures. And while we're very proud of the work we've done on WebKit security, the fact is that it’s getting harder and harder for us to make a big impact anymore.
The big issue is a side effect of Chrome’s design. While our architecture has tremendous strengths (beyond just security), it’s also very different from other WebKit-based browsers, and grows even more so with the rest of the WebKit project's increasing focus on the WebKit2 layer. These differences have forced us to make increasingly difficult decisions, like sidelining major security enhancements that don’t fit well with WebKit. Meanwhile, we were regularly handling security regressions resulting from things like differing release schedules, and maintaining legacy behavior required by WebKit as an API. These growing pains are common enough when a project like WebKit evolves to encompass such a broad set of consumers, but eventually you can reach a point where the burden on some members is just too high.
So, with the Blink project we now have a chance to fix quite a bit of technical security debt that’s accumulated over the years. These changes are all things that fit well with Chrome’s architecture, but were not viable in WebKit given their impact on other platforms. Some of our immediate changes will include improvements to our basic memory hardening in Blink. We plan on making a number of memory-safety changes, like switching to bounds-checked containers and adding integrity checks at different points in HTML processing and rendering. And one really exciting development will be broad deployment of something we call binding integrity, which ensures that DOM objects are valid at the point they’re bound to JavaScript (nearly eliminating first-order stale pointer and type confusion vulnerabilities in the DOM).
Longer term changes will involve things like refactoring our loading, navigation, and history handling. The nature of bugs in these layers tends to be very subtle and complicated, and is usually due to WebKit’s behavior triggering discontinuities in Chrome’s architecture (e.g. inconsistent navigation state between processes). These issues have led to an array of vulnerabilities including: remote code execution, UXSS, spoofing, and sandbox escapes. With Blink we already have a good sense of how we’ll refactor these layers to directly reflect Chrome’s architecture. As a result, we expect to eliminate certain families of Chrome-specific vulnerabilities entirely.
Of course, the best part of making these architectural changes is that we’ll be able to move forward on some really big security efforts like Site Isolation <goo.gl/ZZttn>, which will allow Chrome’s sandbox to enforce the Web’s origin model at a process level. The practical impact is that even a compromised sandbox process would not be able to manipulate data from sites other than the one that originated it. This is particularly valuable on a platform like Chrome OS, which has an extremely robust sandbox. It means that code execution bugs will become dramatically less dangerous, and most UXSS bugs will be eliminated.
So, from my perspective Blink is an unambiguously positive thing for Chrome security, and I expect Chrome’s users to start feeling the security improvements over the coming months.
#chrome #blink #security
View 20 previous comments
OK That was a trip. I have read a LOT of the Blink document. Makes me wish I was 35 and full of excitement and writing code 12+ hours a day. The eco structure is NOT the COBOL I started writing in 1972.
I am now a consumer of this wonderful work. I am a Chrome book user and proponent.
So GOOD JOB Google.Apr 4, 2013
Great info!
I'm following up on the pointers
and then back to work :-)Apr 4, 2013
+Justin Schuh Been doing a lot of reading about Blink over the last 24hrs - mostly positive it seems. Thanks for your comments and information. The more the better. Cheers.Apr 4, 2013- Are there any more detailed descriptions or bugs or source code about what you mean by "binding integrity"? I work on Firefox bindings, so I'm curious what this entails.Apr 4, 2013
Awesome. Yet again one of the biggest trends of the web (WebKit) is doomed to become obsolete quite soon :DApr 4, 2013
+Andrew McCreight, here's a tracking bug http://crbug.com/226633
I don't know how your bindings work, and this may be very specific to our architecture and other memory mitigations we have in place. So, it may or may not be of interest to you.Apr 4, 2013
Add a comment...