Pwning the Ladybird Browser
jessie.cafe
jessie.cafe
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!
We're working on integrating with Swift, but despite the team's earnest efforts, Swift/C++ interop is still young and unstable.
On a personal note, I'm increasingly feeling like "C++ with a garbage collector" might actually be a reasonable tool for the task at hand. Watching the development of Fil-C in this space..
which is great.
I never learned swift but I can add features easily now or create 1-day projects using swiftUI that makes great macOS native UI's.
V8 also has torque which I think to some degree also fits into that type of mindset.
careful, last time someone said that we got Rust
C# is more platform independent. Has a well-tested GC.
Upon destruction, the non-resizable vector will automatically return the contents back to the original resizable vector. (It's somewhat analogous to borrowing a slice in Rust.)
While it wouldn't necessarily prevent you from doing the flawed/buggy thing you were trying to do, it would prevent it from resulting in a memory vulnerability.
[1] https://github.com/duneroadrunner/scpptool#xslta_vector-xslt...
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.
Minimize unsafe, auditing libs with Geiger, and minimizing outside dependencies to a few reliable vendors, is what is practically needed.
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.
Today, I learned about Text Fragment Identifiers [0]. Thanks, very handy!
Firefox 131 and up will highlight the relevant portion on the page but can't create new links in a user-friendly fashion.
It's not built-in, but there is https://addons.mozilla.org/en-US/firefox/addon/link-to-text-...
Cool regardless.
So no, an exploit like this is not just “of academic value” even in a sandboxed browser.
https://awesomekling.github.io/Memory-safety-for-SerenityOS/
Their GitHub has 0,3% Swift code. They said they start once Swift 6 is out. It has been out for months. So either they abandoned Swift or haven’t really started or they are really really slow to start using it. All three options are against the article being outdated, wouldn’t you agree?
At least C++ has mechanisms to write safer code, provided one makes use of them, even if still there are issues.
To use a modern example renaming the JavaScript file extension to a Typescript one, only gets you so far.
Then one can make use of Typescript's type system, or switch to Elm to the next level.
I'm pretty sure that everyone does and did, because almost nobody wrote a browser in C either, never mind in 2018.
NetSurf from 2002 is the only one I can find?
edit: I should say after the first set, because Lynx and Mosaic are C.
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.