The write up can be found here. This is a bug in the webaudio component I discovered in March 2020. Chromium issue ticket can be found here.
The exploit is tested on Ubuntu 18.04 LTS, version 80.0.3987.137, with the following build config: (Probably can reduce symbol level)
is_debug=false
symbol_level = 2
blink_symbol_level = 2
Offsets and object sizes used are based on the linux build.
The exploit is mostly reliable when testing on localhost with python SimpleHTTPServer. However, it is not 100% reliable. This is due to the hardcoded offset between the address of a memory bucket that was leaked and the memory bucket that is actually used to store controlled data. This offset is used in calculateControlledAddress:
//Hardcoded offset between heap bins.
let controlledAddress = bigIntView[0] + 0x184798n;
This mostly fail when there is a broken pipe problem with the SimpleHTTPServer, which happens when the browser is not shutdown properly (shutdown by Ctrl+C rather than closing it from UI) Reliability can probably be improved by using memory buckets that are closer together, or just by putting the whole thing inside an out-of-process-iframe so that if it crashed, it can be restarted from the parent. (Although the bucket offset would need to be tuned again in this case)
The exploit takes a couple of minutes to run. If successful, it will overwrite memory permission for a page that holds our controlled data and will print out the address of this page. It can then be verified that the memory permission has been written to rwx for that page using /proc/<id>/maps (the renderer can be easy to spot by as it should consumed about 400Mb of memory). After that, executing shell code is easy, although I have not included or executed any shell code in this exploit.