4 ms·
Yes parsers are already sandboxed, and violating the sandbox boundary is where the actual valuable exploit is. Parser vulns are near worthless without the rest
by brigade 3y ago
Yes parsers are already sandboxed, and violating the sandbox boundary is where the actual valuable exploit is. Parser vulns are near worthless without the rest of the chain building on it, and the millions of man-years it would take to re-write every last one of them as "provably correct" is better spent hardening sandbox and privilege boundaries.
Which is a completely different problem than simply rewriting things in a safe language.
- alkonaut 3y agoWhat is the cause of the sandbox escape in this case? Somewhere (too high in the stack) there is a C-ish program where someone does pointer arithmetic or an array deref in C which is the same thing.
- brigade 3y agoAre you asking what the full exploit chain is here specifically? Because that obviously hasn't been written up yet. But for the last one, it's the difference between https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-into-nso-zero-click.html https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-i... (parser vulnerability leading to not-really arbitrary code execution and memory corruption) and https://googleprojectzero.blogspot.com/2022/03/forcedentry-sandbox-escape.html https://googleprojectzero.blogspot.com/2022/03/forcedentry-s... (logic errors leading to a sandbox escape) Notably, the sandbox escape itself did not do anything that would have been prevented by a memory safe language. The security model of a sandboxed process is that even full arbitrary code execution cannot do anything the sandbox says the process cannot do, and the process the parsers run in is sandboxed to only be able to communicate to other processes through very limited interfaces that have no access to network or disk.