There are several topics related to V8 security that I have not yet discussed. This post will cover some areas that are related to bug hunting, such as security mechanisms already employed by V8 and Chrome. The intent is to provide some more resources for people interested in V8 security research.
Besides reading through the codebase, many times the best way to get involved is through practice. Studying past vulnerabilities can help lead to discovering new ones. And when one bug is found, there’s a decent chance that similar vulnerabilities exist. Below are some ways to find disclosed bugs in V8 that can help with finding future ones.
While V8 has its own list of bugs, many are also posted within the larger Chromium tracking list. This is where anyone can report bugs to Google, which every takes totally seriously and never posts any joke bugs.
Thankfully, there are several filters to locate security-related bugs. Combining the filters isn’t always intuitive, but one that I usually go with is
Bug reports are very helpful for getting started in V8 security research. Many times, these reports contain PoCs, explanations of the code base, and a discussion about how the bug was caused and how it will be fixed. When new exploitation techniques are discovered, they are usually discussed in the most detail in one of these reports.
If you don’t have time to regularly check the bug trackers, the official Chrome Releases page details all of the major vulnerabilities that were patched over the past 6 weeks. This is generally easier to search for bugs in V8 because it contains a concise list with short descriptions for each vulnerability. However, it only publishes bugs once they have been patched, and at larger time intervals.
Meanwhile, if you have a lot of time to search for the latest patches, you should look through the open-source V8 log or the GitHub mirror. From your terminal you can run
git log origin/master to look through the master branch log, even if you are on an old commit locally. Most of the code changes are non security-related. However, commits often have a bug ID embedded in the commit message. This means that you can cross-reference IDs from the bug tracker and the changelog to see if a bug is a security issue or not. The interesting part about this is that some bugs are publicly disclosed and patched before applications, like Chrome, implement these patches during regular release cycles. “In effect, there’s a window of opportunity for attackers ranging from a couple days to weeks in which the vulnerability details are practically public yet most of the users are vulnerable and cannot obtain a patch.” -Exodus Blog Diffing these patches can help complete root cause analysis before the bug tracker opens the issue with more details.
The V8 team manages a twitter account as well as a blog. Both of these post information about changes in V8, usually from a development perspective, but changes often mean new features that need to be looked into. These blogs often add a lot of explanation that the code does not readily provide.
While it is not V8-focused, the Google Project Zero Blog often does research on browser vulnerabilities. They have written a few articles on Chrome and V8. These go into great depth on browser exploitation and they will likely release similar posts in the future.
Some fuzzing products from outside Google have been introduced as well, such as Fuzzilli from Samuel Groß. While it was not built specifically for V8, you can see how it was ported in the GPZ repo. It has already found bugs in V8, such as 1072171. Another recently introduced fuzzer, DIE, from Georgia Tech’s lab, has also discovered multiple vulnerabilities. Both have enough documentation to get started with relatively little work. There is also a very good walkthrough from Patrick Ventuzelo on fuzzing Liftoff using Dharma.
Finally, the Chromium blog has a helpful guide for getting started with fuzzing and creating new testing methods. Specifically this guide outlines the process for introducing a new fuzzer to V8, much like how they ported a new WebAssembly fuzzer.
When you look through the V8 code, you will notice a lot of CHECK and DCHECK macros. CHECK statements assert conditions that would have security implications if not met. These will force the browser to crash in order to prevent more serious consequences. DCHECK statements are only present in the debug build, and are meant to validate pre-conditions and post-conditions that should always be true. These statements can help fuzzers locate errors more closely to the source. For example, a type confusion may not cause a crash. Even if it does, it may take several hours to track down where the actual mistake is located in the code. However, DCHECKS can find where an assumption was broken and narrow the search scope.
There are a wide variety of security mechanisms built into V8; including fuzzing, sanitization, manual code review, compartmentalization, and a recently increased bug bounty program. The Security Brag Sheet has a list of protections put in place by the Chrome team for the entire browser. Some of these are specific to V8, but many are general techniques to improve software. Anyone who is interested in improving V8 security should look into these areas. This post hopefully introduced some aspects of bug tracking and hunting that will help with starting points for additional bug discovery.
A window of opportunity: exploiting a Chrome 1day vulnerability by Exodus Intelligence
Chromium Blog: Fuzzing for Security
GTAC 2013: AddressSanitizer, ThreadSanitizer and MemorySanitizer – Dynamic Testing Tools for C++