5 ms·

Pwning the Ladybird Browser

332 points by todsacerdoti 2y ago

snvzz 2y ago
Of academic value, as ladybird has little in terms of sandboxing yet. Cool regardless.
- nneonneo 2y 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 2y ago
    With site isolation there's not loads of other websites in the renderer these days at least.
    - saagarjha 2y ago
      Assuming your site isolation works, at least. Some browsers were having trouble with it until pretty recently.
cadamsdotcom 2y ago
This is a big landmark. Ladybird has come far enough to be a worthy target for security research!
webprofusion 2y 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 2y ago
  Ah the github links are indeed there, my bad, it's a good write up.
neilv 2y 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 2y ago
  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%20browser%20in 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 2y 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.
    - sebmellen 2y ago
      Elsewhere… where? WebKit?
      - GoblinSlayer 2y ago
        noscript
  - oesa 2y ago
    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 https://web.dev/articles/text-fragments#text_fragments
LegionMammal978 2y ago
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 2y ago
  the solution? #[deny(unsafe_code)]
  - Ygg2 2y ago
    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.
    - deleted 2y ago
      [deleted]
  - VWWHFSfQ 2y ago
    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 2y 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 2y 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 2y 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. https://awesomekling.github.io/Memory-safety-for-SerenityOS/ https://awesomekling.github.io/Memory-safety-for-SerenityOS/
  - kragil 2y ago
    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 2y ago
      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 2y ago
        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 https://github.com/sophiajt/june
    - circl_lastname 2y ago
      Current blockers to swift usage are found here: https://github.com/LadybirdBrowser/ladybird/issues/933 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
awesomekling 2y ago
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 2y ago
  so is this gonna stay in c++ or are you still moving to swift
  - awesomekling 2y ago
    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 2y ago
      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/GregKamradt/status/1848045525473677314 https://x.com/wycats/status/973761496277704704 https://x.com/wycats/status/973761496277704704
qiu3344 2y ago
Haven't seen anyone using dwm in a while. I forgot how lean and mean it is =)
deleted 2y ago
[deleted]

332 points by todsacerdoti 2y ago

snvzz 2y ago

Of academic value, as ladybird has little in terms of sandboxing yet. Cool regardless.

nneonneo 2y 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 2y ago
  With site isolation there's not loads of other websites in the renderer these days at least.
  - saagarjha 2y ago
    Assuming your site isolation works, at least. Some browsers were having trouble with it until pretty recently.

cadamsdotcom 2y ago

This is a big landmark. Ladybird has come far enough to be a worthy target for security research!

webprofusion 2y 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 2y ago
Ah the github links are indeed there, my bad, it's a good write up.

neilv 2y 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 2y ago
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%20browser%20in 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 2y 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.
  - sebmellen 2y ago
    Elsewhere… where? WebKit?
    - GoblinSlayer 2y ago
      noscript
- oesa 2y ago
  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 https://web.dev/articles/text-fragments#text_fragments

LegionMammal978 2y ago

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 2y ago
the solution? #[deny(unsafe_code)]
- Ygg2 2y ago
  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.
  - deleted 2y ago
    [deleted]
- VWWHFSfQ 2y ago
  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 2y 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 2y 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 2y 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. https://awesomekling.github.io/Memory-safety-for-SerenityOS/ https://awesomekling.github.io/Memory-safety-for-SerenityOS/
- kragil 2y ago
  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 2y ago
    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 2y ago
      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 https://github.com/sophiajt/june
  - circl_lastname 2y ago
    Current blockers to swift usage are found here: https://github.com/LadybirdBrowser/ladybird/issues/933 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

awesomekling 2y ago

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 2y ago
so is this gonna stay in c++ or are you still moving to swift
- awesomekling 2y ago
  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 2y ago
    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/GregKamradt/status/1848045525473677314 https://x.com/wycats/status/973761496277704704 https://x.com/wycats/status/973761496277704704

qiu3344 2y ago

Haven't seen anyone using dwm in a while. I forgot how lean and mean it is =)

deleted 2y ago

[deleted]