Google Chrome fuzzing conclusion

blog.redteam.pl 4 lat temu

Background

This post will be a summary of a tiny fuzzing exercise that I was moving over the course of a fewer 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 utilized for test case generation due to the reason I wanted to start as shortly as possible.

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

Results

In full 8 bugs were reported, 2 of which turned up to be duplicates. All vulnerabilities but 1 were Use-After-Free’s. Six of the reported bugs were in the browser process meaning they could be utilized 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 simply a complete list of the submitted issues:

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

Summary

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

Portals

Details about portal component fuzzing results have been described in the first blog post [https://blog.redteam.pl/2019/12/chrome-portal-element-fuzzing.html]. 2 months after publishing information on the blog 1 more issue has been identified (crbug #1041406) so it was worth to keep it moving for a while. It is besides worth noting that all vulnerabilities in portals were affecting the browser process. Depending on how this functionality will make in the future I believe it will stay an interesting mark 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 truly focusing on that functionality (at least at the time of uncovering the issues) and the bugs were found by accident. As can be observed in 1 of the test cases that is public (crbug #1055393) there is nothing truly circumstantial for accessibility features in it. As this is simply a functionality not enabled by default, in order to get results a --force-renderer-accessibility flag should 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 mark 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. erstwhile the article was published the functionality has been already moved to CSS and at the minute of publishing this post no further issues have been discovered. nevertheless due to its impact on rendering pages it may give any results in connection with another features.

ANGLE


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

Idź do oryginalnego materiału