This is awesome! Really great write-up, and solid work by Jessie :^)

The Ladybird codebase is generally very defensive, but like every browser, our JavaScript engine is slightly less so (in the pursuit of performance.)

There are architectural lessons to learn here beyond just fixing the bugs found. We've since replaced these allocations (+ related ones) with callee-specific stack memory instead of trying to be clever with heap allocation reuse.

We're also migrating more and more of our memory management to garbage collection, which sidesteps a lot of the traditional C++ memory issues.

As others have mentioned, sandboxing & site isolation will make renderer exploitation a lot less powerful than what's demonstrated here. Even so, we obviously want to avoid it as much as possible!

Reentrancy bugs like this one are surprisingly common. Having reviewed lots of unsafe Rust code, unnoticed calls into outside code (that can then reenter your own code or modify your data structures, blowing everything up) is one of the most common soundness issues I've found across different projects.

The main solutions seem to be either restricting how possibly-invalidated data can be held (e.g., safe references in Rust), or having some coloring scheme (e.g., "pure" annotations) to ensure that the functions you call are unable to affect your data. Immutable languages can mitigate it somewhat, but only if you have the discipline to maintain a single source of truth for everything, and avoid operating on stale copies.

This is a big landmark. Ladybird has come far enough to be a worthy target for security research!

If this is all-new development, wouldn't it be good for the emphasis to be on correctness and security, as part of the design and coding itself?

That's something that you use fuzzing as one way to detect a failure of, not as the means of achieving correctness and security.

I'm not picking on Ladybird here specifically. Chrome and Firefox provide constant streams of security vulnerabilities. But it would be nice if Ladybird didn't start with the same problems that might be attributed to huge legacy code bases.

tbh i kinda love how they're just going for it and building from scratch but i always wonder how much focus on security upfront actually changes things long-term-you think building with fun in mind ends up missing critical stuff or does it keep devs more engaged

Of academic value, as ladybird has little in terms of sandboxing yet.

Cool regardless.

Haven't seen anyone using dwm in a while. I forgot how lean and mean it is =)

With decades and decades of memory safety lessons in the books, it's hard to imagine how C++ was the language of choice when starting new browser from scratch in 2018.

Always good to start the discussion but the article doesn't seems to link to an issue on the Ladybird github repo, which I would expect in the case of academic disclosure etc.

Obviously nobody is really using Ladybird yet and there will be many more such issues to address, so now is a good time to evaluate how to avoid such mistakes up front.