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.
cadamsdotcom · 4h ago
This is a big landmark. Ladybird has come far enough to be a worthy target for security research!
neilv · 4h ago
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.
esprehn · 3h ago
Ladybird comes from Serenity OS which has a focus of having fun and being pragmatic while building everything from scratch incrementally.
I appreciate their pragmatism though, it's allowed them to catch up to other alternative browsers in WPT coverage very quickly.
neilv · 3h ago
OK, fun is valid. And it's good to have expectations set.
Open source people who are looking for a more trustworthy browser than Firefox will have to look elsewhere, though.
gitroom · 2h ago
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
kavefish · 1h ago
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.
ironmagma · 1h ago
Answer is here, although the article is outdated and the most recent news is that they are rewriting the browser at least in Swift.
Of academic value, as ladybird has little in terms of sandboxing yet.
Cool regardless.
nneonneo · 4h ago
Even in a modern browser, a renderer exploit (the most sandboxed portion of the browser) gives you access to a large attack surface - the browser process via IPC, the kernel via syscalls, and loads of data from other websites.
So no, an exploit like this is not just “of academic value” even in a sandboxed browser.
esprehn · 4h ago
With site isolation there's not loads of other websites in the renderer these days at least.
webprofusion · 4h ago
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.
webprofusion · 4h ago
Ah the github links are indeed there, my bad, it's a good write up.
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.
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.
They do plan to switch to Swift: https://ladybird.org/#:~:text=Why%20build%20a%20new%20browse...
I appreciate their pragmatism though, it's allowed them to catch up to other alternative browsers in WPT coverage very quickly.
Open source people who are looking for a more trustworthy browser than Firefox will have to look elsewhere, though.
https://awesomekling.github.io/Memory-safety-for-SerenityOS/
Cool regardless.
So no, an exploit like this is not just “of academic value” even in a sandboxed browser.
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.