4 ms·

On the v8 engine's blog, it is claimed that most of its vulnerabilities are caused by logic issues which Rust wouldn't help with. Perhaps it's a similar situat

On the v8 engine's blog, it is claimed that most of its vulnerabilities are caused by logic issues which Rust wouldn't help with. Perhaps it's a similar situation for Ladybird. >Memory safety remains a relevant problem: all Chrome exploits caught in the wild in the last three years (2021 – 2023) started out with a memory corruption vulnerability in a Chrome renderer process that was exploited for remote code execution (RCE). Of these, 60% were vulnerabilities in V8. > V8 vulnerabilities are rarely "classic" memory corruption bugs (use-after-frees, out-of-bounds accesses, etc.) but instead subtle logic issues which can in turn be exploited to corrupt memory. As such, existing memory safety solutions are, for the most part, not applicable to V8. In particular, neither switching to a memory safe language, such as Rust, nor using current or future hardware memory safety features, such as memory tagging, can help with the security challenges faced by V8 today. See: https://v8.dev/blog/sandbox https://v8.dev/blog/sandbox

kroolik 2y ago
I believe the fact that V8 vulnerabilities are not "classic" memory corruption can be attributed to their developers' experience and review processes. This doesn't imply, though, that another project in C++ will share these traits.
debugnik 2y ago
40% may not be a majority, but it's still close to half of all Chrome exploits in the wild, and they could be avoided with a memory-safe toolchain. (Doesn't have to be Rust.) As for the other 60%, they point to logic errors as the root cause, but that's true of all memory corruption bugs: they wouldn't exist if there weren't logic errors behind them. The actual difference here is that the vulnerabilities are either in the machine code generated by the JIT (e.g. type confusion), rather than V8's own code; or they're in code they insist must be memory-unsafe for performance reasons. So the takeaway there should be that JS engines for hostile code should either not use a JIT at all, nor memory-unsafe code paths, or use stronger tools to verify the correctness of the JIT and those code paths. But hey, retaining the capability to speed up bloated web apps ever so slightly is more important that
timeon 2y ago
> which Rust wouldn't help with Technically no. But if you can decrease those 40% where it could help you can than focus more on the logic issues. Maybe.

kroolik 2y ago

I believe the fact that V8 vulnerabilities are not "classic" memory corruption can be attributed to their developers' experience and review processes. This doesn't imply, though, that another project in C++ will share these traits.

debugnik 2y ago

40% may not be a majority, but it's still close to half of all Chrome exploits in the wild, and they could be avoided with a memory-safe toolchain. (Doesn't have to be Rust.) As for the other 60%, they point to logic errors as the root cause, but that's true of all memory corruption bugs: they wouldn't exist if there weren't logic errors behind them. The actual difference here is that the vulnerabilities are either in the machine code generated by the JIT (e.g. type confusion), rather than V8's own code; or they're in code they insist must be memory-unsafe for performance reasons. So the takeaway there should be that JS engines for hostile code should either not use a JIT at all, nor memory-unsafe code paths, or use stronger tools to verify the correctness of the JIT and those code paths. But hey, retaining the capability to speed up bloated web apps ever so slightly is more important that

timeon 2y ago

> which Rust wouldn't help with Technically no. But if you can decrease those 40% where it could help you can than focus more on the logic issues. Maybe.