4 ms·
Interested readers should check out the author's earlier work exploiting CVE-2019-9810: https://github.com/0vercl0k/CVE-2019-9810 https://github.com/0vercl0k/CV
by crumbshot 7y ago
Interested readers should check out the author's earlier work exploiting CVE-2019-9810: https://github.com/0vercl0k/CVE-2019-9810 https://github.com/0vercl0k/CVE-2019-9810
And their fantastically detailed writeup of a PoC they wrote for that vulnerability: https://doar-e.github.io/blog/2019/06/17/a-journey-into-ionmonkey-root-causing-cve-2019-9810/ https://doar-e.github.io/blog/2019/06/17/a-journey-into-ionm...
This exploit is different in that they use the arbitrary read/write primitive gained by CVE-2019-9810 to flip a couple of bits and patch out a few instructions with the effect of removing the security boundary between a normal web page and XPCOM. The interesting difference in this exploitation approach is there's no need for ROP chains and shellcode, as you have all the XPCOM components available to use.
Once they're in that privileged context in the content process, they escape its sandbox by exploiting CVE-2019-11708. This works by sending an particular IPC message to the parent process, that causes a web page of the exploiter's choice to load in that process. In this case, the choice is to exploit CVE-2019-9810 again, then use XPCOM components to drop an executable to disk and run it.
Awesome work, and a real pleasure to read, it's satisfying to see such well-commented and clear exploit code.