Google Chrome fuzzing conclusion

Background

This post will be a summary of a small fuzzing exercise that I was running over the course of a few months (from May 2019 to March 2020) where the focus was mostly on experimental and non-default features of the Google Chrome browser. As described in the first blog post [https://blog.redteam.pl/2019/12/chrome-portal-element-fuzzing.html] domato [https://github.com/googleprojectzero/domato] was used for test case generation due to the reason I wanted to start as soon as possible.

Initially it was only about the <portal> element. However various other features were added to the fuzzing grammar over time with some of them providing good results as well. 

Results

In total eight bugs were reported, two of which turned up to be duplicates. All vulnerabilities except one were Use-After-Free’s. Six of the reported bugs were in the browser process meaning they could be used for sandbox escape. Vulnerabilities were reported in the following components:
  • portals (4 bugs reported, 2 duplicates)
  • accessibility (2 bugs reported)
  • display locking (1 bug reported)
  • ANGLE (1 bug reported)

Below is a complete list of the submitted issues:

Total amount of bounty received from Google was $68,000.

Summary

Here is a short summary about the functionalities that were targeted/affected during this fuzzing exercise.

Portals

Details about portal element fuzzing results have been described in the first blog post [https://blog.redteam.pl/2019/12/chrome-portal-element-fuzzing.html]. Two months after publishing information on the blog one more issue has been identified (crbug #1041406) so it was worth to keep it running for a while. It is also worth noting that all vulnerabilities in portals were affecting the browser process. Depending on how this functionality will develop in the future I believe it will remain an interesting target not only for fuzzing and it is worth to keep an eye on it.

Accessibility

Fuzzing accessibility was not described in a separate post. I was not really focusing on that functionality (at least at the time of finding the issues) and the bugs were found by accident. As can be observed in one of the test cases that is public (crbug #1055393) there is nothing really specific for accessibility features in it. As this is a functionality not enabled by default, in order to get results a --force-renderer-accessibility flag has to be passed during Chrome execution. As with portals all vulnerabilities affected the browser process. Additionally just by looking at the diagram taken from the AOM explainer [https://github.com/WICG/aom/blob/gh-pages/explainer.md]:




a conclusion can be drawn that it is an interesting target by itself (DOM tree → accessibility tree transformation + read via native API) and in my opinion more bugs are to be found here.

Display Locking

This case was described in my second blog post [https://blog.redteam.pl/2020/04/google-chrome-display-locking-fuzzing.html], where more details can be found. When the article was published the functionality has been already moved to CSS and at the moment of publishing this post no further issues have been discovered. Nevertheless due to its impact on rendering pages it may give some results in connection with other features. 

ANGLE


As with accessibility this was not the area I was focusing on and a vulnerability was identified using regular DOM fuzzing. Surprisingly the minimized test case was very simple and it seemed unlikely that it has not been already detected. At the moment of writing this post the issue is still not public (CVE-2020-6463), but when it will get derestricted you will see what I meant.

No comments:

Subscribe Posts Comments