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.
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.
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.
https://awesomekling.github.io/Memory-safety-for-SerenityOS/
snvzz•5h ago
Cool regardless.
nneonneo•4h ago
So no, an exploit like this is not just “of academic value” even in a sandboxed browser.
esprehn•4h ago