It looks like the bug is that there is a way for the renderer (sandboxed) process to trigger the browser (unsandboxed) process to duplicate an arbitrary windows kernel object handle. When you duplicate a handle, you can restrict access, or allow the duplicate to have full access as the original - unfortunately this one is duplicating preserving all the capabilities/access of the original handle.

Now for the POC exploit - it so happens that 0x108 is typically a thread handle for a thread in the browser process. What can you do with a thread handle? You can pause execution of that thread, set its register values (including instruction pointer), resume execution.

If kernel32.dll loads at the same address in each process, we can find some set of instructions in it that write a register's value to another register's address. If we set the instruction pointer to that instruction, we've unlocked the ability to write arbitrary memory in the unsandboxed process.

Finally, we can call other Windows APIs (by finding the address of the function to call and setting instruction pointer to it)- in the POC, they write "calc.exe" to a string, then call the system api to launch calculator.