[HN Gopher] Pwning the Ladybird Browser
___________________________________________________________________
Pwning the Ladybird Browser
Author : todsacerdoti
Score : 308 points
Date : 2025-04-30 23:59 UTC (23 hours ago)
(HTM) web link (jessie.cafe)
(TXT) w3m dump (jessie.cafe)
| snvzz wrote:
| Of academic value, as ladybird has little in terms of sandboxing
| yet.
|
| Cool regardless.
| nneonneo wrote:
| 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 wrote:
| With site isolation there's not loads of other websites in
| the renderer these days at least.
| saagarjha wrote:
| Assuming your site isolation works, at least. Some browsers
| were having trouble with it until pretty recently.
| cadamsdotcom wrote:
| This is a big landmark. Ladybird has come far enough to be a
| worthy target for security research!
| webprofusion wrote:
| 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 wrote:
| Ah the github links are indeed there, my bad, it's a good write
| up.
| neilv wrote:
| 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 wrote:
| Ladybird comes from Serenity OS which has a focus of having fun
| and being pragmatic while building everything from scratch
| incrementally.
|
| 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.
| neilv wrote:
| 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.
| sebmellen wrote:
| Elsewhere... where? WebKit?
| GoblinSlayer wrote:
| noscript
| oesa wrote:
| off topic, but I have never seen a link like yours before.
|
| Today, I learned about Text Fragment Identifiers [0]. Thanks,
| very handy!
|
| [0] https://web.dev/articles/text-fragments#text_fragments
| rzzzt wrote:
| Chrome and Edge have a context menu item to create a link
| like this when you select text ("Copy link to highlight").
|
| Firefox 131 and up will highlight the relevant portion on
| the page but can't create new links in a user-friendly
| fashion.
| TheDong wrote:
| > But [firefox] 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-...
| LegionMammal978 wrote:
| 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.
| ramon156 wrote:
| the solution? #[deny(unsafe_code)]
| Ygg2 wrote:
| Eh. It will work with your code but at some point your
| dependencies will have to dive into unsafe (e.g. calling C
| libs/kernel, SIMD, ASM by hand, etc.).
|
| Minimize unsafe, auditing libs with Geiger, and minimizing
| outside dependencies to a few reliable vendors, is what is
| practically needed.
| VWWHFSfQ wrote:
| Any reasonably sophisticated web browser is going to require
| a decent amount of unsafe {} if only just for performance
| reasons. Obviously would be much easier to audit though.
| gitroom wrote:
| 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 wrote:
| 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 wrote:
| Answer is here, although the article is outdated and the most
| recent news is that they are rewriting the browser at least in
| Swift.
|
| https://awesomekling.github.io/Memory-safety-for-SerenityOS/
| kragil wrote:
| How is it outdated??
|
| 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?
| ironmagma wrote:
| Because the article is from 2022 and says that they will
| use a custom language called Jakt which didn't pan out, it
| seems. Yes, I am also eager for the Swift rewrite to get
| off the ground.
| pjmlp wrote:
| Mostly because the author switched focus to yet another
| language, and eventually decided to focus on something
| else instead of programming languages.
|
| https://github.com/sophiajt/june
| circl_lastname wrote:
| Current blockers to swift usage are found here:
| https://github.com/LadybirdBrowser/ladybird/issues/933
| Rising tide lifts all boats, by trying to use Swift
| seriously, they're finding and helping fix bugs in the
| compiler
| favorited wrote:
| One of the primary Ladybird devs just gave a lightning talk
| at CppCon about porting their HTML parser from C++ to
| Swift.
|
| https://www.youtube.com/watch?v=KCRx1jE6DnY
| pjmlp wrote:
| One would think the same of C, where exploits trace all the way
| back to Morris worm in 1988, that is 36 years of thinking the
| problem are the developers, not the language, with new projects
| being started every day still.
|
| 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.
| pessimizer wrote:
| > One would think the same of C
|
| 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.
| Jaxan wrote:
| When they started, the plan was mostly to have fun and see how
| far you can get when creating an OS from scratch. So picking a
| language in which they are experienced makes sense in that
| context.
| circl_lastname wrote:
| The browser was not started with the idea of taking over the
| main focus of development, it was just another part of an
| already pretty large hobby OS project
| yencabulator wrote:
| Fine. 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 operating system from scratch in
| 2018.
| adamrt wrote:
| It really isn't that hard to imagine someone starting a fun
| hobby project in the language they enjoyed and were the
| most comfortable with.
| yencabulator wrote:
| Dunno. It really is. Debugging memory corruption bugs in
| complex one-memory-space systems is very much not fun.
| circl_lastname wrote:
| Nothing a little printf (or dbgln as it is known as in
| Serenity-Ladybird land) can't fix
| awesomekling wrote:
| 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!
| payphonefiend wrote:
| so is this gonna stay in c++ or are you still moving to swift
| awesomekling wrote:
| 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..
| soundnote wrote:
| What'd be the effect of Swift be on the possibility of a
| Windows port? I know anything end user friendly is ages
| away, but I don't live in Apple land, and neither does most
| of the world. Apple has a monopoly on iOS and huge market
| share on Mac, and is still at 20% or something.
|
| https://x.com/GregKamradt/status/1848045525473677314
|
| https://x.com/wycats/status/973761496277704704
| circl_lastname wrote:
| The core Swift Lang has is being made more independent of
| Apple, and can be compiled for an increasing number of
| platforms thanks to the LLVM-based compiler
| tough wrote:
| You can even build swiftUI apps without opening Xcode at
| all nowadays (albeit no code signing)
|
| 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.
| the_mitsuhiko wrote:
| I'm honestly not at all familiar with browsers but I really
| do wonder if a custom language wouldn't be a reasonable
| tradeoff. It's not all that insane as that is a path that
| has been walked before. For instance FoundationDB has their
| own syntax to manage their actor system which just
| transpiles to C++: https://github.com/apple/foundationdb/bl
| ob/main/flow/README....
|
| V8 also has torque which I think to some degree also fits
| into that type of mindset.
| int_19h wrote:
| Out of curiosity, why not C# at this point? It's pretty
| hard to marry C++ with a _high-performant_ garbage
| collector, since underlying language semantics does not
| allow for e.g. compacting GCs.
| safercplusplus wrote:
| 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 wrote:
| Very interesting, I was not familiar with your project.
| Thanks for sharing it here!
| qiu3344 wrote:
| Haven't seen anyone using dwm in a while. I forgot how lean and
| mean it is =)
___________________________________________________________________
(page generated 2025-05-01 23:02 UTC)