Ah I see what you mean :-) We'll yes I left out the RCE as I'm not an RCE person, I look for sandbox escapes and privilege escalation bugs. The injection of a DLL is to test rather than as an exploit.
I was originally going to write about using the same bug in Firefox. The default content sandbox in FF is basically the same as Chrome GPU, so any untrusted HTML/JS coming from the web could exploit RCE to get into a sandboxed process where this bug could be used. I decided considering they're using the Chromium sandbox code it really should be about Chrome.
That said, this sandbox escape isn't being presented for practical reasons. It'd be incredibly noisy to do and potentially unreliable due to the various mitigations you have to circumvent. Any "real" attacker would likely use an exploit in the kernel's WIN32K component which is accessible from GPU.
The vulnerability is in Windows 10. Windows 10 has been fixed. It's not clear in the article what other mitigations are in place in Firefox to make exploitation more difficult.
Basically my PoC works exactly the same from Chrome GPU as FF Content Level 5 [1] there was no additional hardening. It was also easier to test as FF doesn't enable the Microsoft DLL signing mitigation should I could just do a direct CreateRemoteThread -> LoadLibrary without messing with KnownDlls.
I was originally going to write about using the same bug in Firefox. The default content sandbox in FF is basically the same as Chrome GPU, so any untrusted HTML/JS coming from the web could exploit RCE to get into a sandboxed process where this bug could be used. I decided considering they're using the Chromium sandbox code it really should be about Chrome.
That said, this sandbox escape isn't being presented for practical reasons. It'd be incredibly noisy to do and potentially unreliable due to the various mitigations you have to circumvent. Any "real" attacker would likely use an exploit in the kernel's WIN32K component which is accessible from GPU.