[awesomekling]

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!

[safercplusplus]

This particular memory vulnerability, as I understand it, was a result of a `ReadonlySpan<>` targeting a resizable vector. A simple technique used by the scpptool-enforced safe subset of C++ to address this situation is to temporarily move the contents of the resizable vector into a non-resizable vector [1] and target the span at the non-resizable vector instead.

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...

[awesomekling]

Very interesting, I was not familiar with your project. Thanks for sharing it here!

[payphonefiend]

so is this gonna stay in c++ or are you still moving to swift

[awesomekling]

Whatever happens, large parts of the codebase + dependencies will be C++ (or C) for the foreseeable future.

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..

[seanhunter]

This is an FAQ

“ Ladybird started as a component of the SerenityOS hobby project, which only allows C++. The choice of language was not so much a technical decision, but more one of personal convenience. Andreas was most comfortable with C++ when creating SerenityOS, and now we have almost half a million lines of modern C++ to maintain.

However, now that Ladybird has forked and become its own independent project, all constraints previously imposed by SerenityOS are no longer in effect.

We have evaluated a number of alternatives, and will begin incremental adoption of Swift as a successor language, once Swift version 6 is released.”

https://ladybird.org/#faq