It’s been a year since the Project zero team published the results of their research about the resilience of modern browsers against DOM fuzzing. They also published Domato, their DOM fuzzing tool that was used to find those bugs. The results of the research were astonishing since Apple Safari, or more specifically, WebKit (its DOM engine) did not fare well in this test. The team decided to revisit the project again using exactly the same methodology and exactly the same tools to see whether the browsers have managed to implement better security mechanisms.
The Test Setup
In the previous research, the fuzzing was initially done against WebKitGTK+ and then all the crashes were tested against Apple Safari running on a Mac. In this research, WebKitGTK+ version 2.20.2 was used.
To improve the fuzzing process, a couple of custom changes were made to WebKitGTK+ . For instance:
- Building WebKitGTK+ with ASan (Address Sanitizer) is now possible
- Changed window.alert() implementation to immediately call the garbage collector instead of displaying a message window.
- Generally, when a DOM bug causes a crash, due to the multi-process nature of WebKit, only the web process would crash, but the main process would continue running. Code was added to crash the main process when the web process crashes
- The team created a custom target binary.
After running the fuzzer for 100.000.000 iterations, the team discovered 9 unique bugs that were reported to Apple.
The bugs are summarized in the table below. All of these bugs have been fixed at the time of release of this blog post.
|Project Zero bug ID||CVE||Type||Affected Safari 11.1.2||Older than 6 months||Older than 1 year|
UAF = use-after-free. OOB = out-of-bounds
Out of the 9 bugs found, 6 affected the release version of Apple Safari, directly affecting Safari users. While this is significantly less than the 17 bugs found a year ago, it is still a notable number, especially since the fuzzer has been public for a long time now.
After the results were in, the team found that most of the bugs were sitting in the WebKit codebase for longer than 6 months, however, only 1 of them is older than 1 year. Also, the team notes that throughout the past year, their fuzzing process came up with 14 bugs but they cannot surely say if these bugs have been resolved or are still live.
The Exploit performed on the bugs
To prove that bugs like this can lead to a browser compromise, an exploit was written for one of them. Out of the 6 issues affecting the release version of Safari, the researchers selected the use-after-free issue to exploit. The details of this issue are well explained in Project Zero’s Blog post. The exploit was successfully tested on Mac OS 10.13.6 (build version 17G65). All the details of the exploit can be seen at bugs.chromium.org.
An interesting aspect of this exploit is that, on Safari for Mac OS it could be written in a very “old-school’ way due to lack of control flow mitigations on the platform. That being said, on the latest mobile hardware and in iOS 12, which was published after the exploit was already written, Apple introduced control flow mitigations by using Pointer Authentication Codes (PAC).
The issues were reported to Apple between June 15 and July 2nd, 2018. On September 17th 2018, Apple published security advisories for iOS 12, tvOS 12 and Safari 12 which fixed all of the issues. Although the bugs were fixed at that time, the corresponding advisories did not initially mention them. The issues described in the blog post were only added to the advisories one week later, on September 24, 2018, when the security advisories for macOS Mojave 10.14 were also published.
The researchers affirm that there were clear improvements in WebKit DOM when tested with Domato. However, the public fuzzer was still able to find a large number of bugs. This is worrying because if a public tool was able to find that many bugs, private tools can be even more effective in exploiting these bugs.
To know more about this experiment, head over to Google Project Zero’s official Blog.