The write up can be found here. This is a bug in Chrome that I reported in September 2020 that is a duplicate of 1115901 and was credited to an anonymous researcher. The GitHub Advisory can be found here and the Chrome issue that I filed here. The bug can be used to escape the Chrome sandbox from a compromised renderer.
The exploit is tested on the 64 bit beta version 86.0.4240.30 of Chrome with the following build config (args.gn), although it affected the stable version 85 of Chrome also:
target_os = "android"
target_cpu = "arm64"
is_java_debug = false
is_debug = false
symbol_level = 1
blink_symbol_level = 1
and build the target chrome_public_apk.
The exploit is tested on Samsung Galaxy A71 with firmware version A715FXXU3ATJ2, Baseband A715FXXU3ATI5 and Kernel version 4.14.117-19828683 and also Pixel 4 with AOSP build ID aosp_flame-userdebug 10 QQ3A.200805.001. Both runs reliably, although a clean renderer process is needed to launch the exploit, which would be the case when a link is clicked from a logged in site, such as email or twitter. On Pixel 3a, the heap spray is off by one object, so there is probably some degrees of dependencies on devices or OS. (Pixel 3a runs kernel version 4.9, whereas the other 2 devices run kernel 4.14, although when it failed on Pixel 3 it'll most likely just throw an exception instead of crashing the renderer) It is very unlikely that it will work on emulators without modifications to the heap spray.
To test, serve the files in this directory from localhost and open tear_down_android_rce_release.html with chrome://inspect/#devices on the device in a new tab. (or do the following from the host machine, which works on Pixel 4 but not on Galaxy A71:
out/<target>/bin/chrome_public_apk run "http://localhost:8000/tear_down_android_rce_release.html"
)
This is the easiest way to ensure that a new renderer process is used for the content (without having to click on it from a logged in context) It should succeed most of the time. When succeeded, The address of a page whose permissioin is overwritten to rwx will be displayed. This can then be verified with adb.
The file out2.mp3 in this directory is a blank mp3 file that can be generated using ffmpeg with the following command:
ffmpeg -f lavfi -i anullsrc=r=4000:cl=mono -t 0.00675 -q:a 9 -acodec libmp3lame out2.mp3