4 ms·

Yes and Google Chrome has invested heavily in sandboxing and still had to ship this as a high-priority fix. I'd say sandboxing in conjunction with memory-safe

by Yeroc 3y ago

Yes and Google Chrome has invested heavily in sandboxing and still had to ship this as a high-priority fix. I'd say sandboxing in conjunction with memory-safe languages is the future.

kentonv 3y ago
The problem is that rewriting existing code into a memory-safe language is a huge investment -- and realistically the world depends on a lot of code built over many decades that cannot be rewritten overnight. Consider that Mozilla created Rust specifically so they could rewrite their browser in it, yet still only a small fraction of Firefox code is Rust today -- much more is still C/C++. Realistically we're going to have a lot of heavily used C/C++ code forever. The singularity will come before we can replace it all. The nice thing about sandboxing and fuzzing can be applied to existing code.
- Yeroc 3y ago
  Yes, but sandboxing and fuzzing are insufficient. As pointed out in the article Google had been fuzzing this library and it didn't find the issue. They even tweaked the fuzzing after this issue was found to specifically target the area of the vulnerability and it apparently still didn't trigger the issue. Google Chrome also implements sandboxing and many areas. It's not feasible everywhere. So for new code / libraries we should default to a memory-safe language.
  - kentonv 3y ago
    I think almost everyone agrees new greenfield projects should not choose C/C++, now that Rust has matured enough and covers essentially the same use cases. But realistically that only solves a tiny fraction of the problem, since realistically new greenfield projects started today will likely take 10+ years to become widely used, if they do at all. WebP was written at a time when C/C++ was still the only viable language in which to write an image compression library. Saying "things like this should be written in Rust!" just doesn't actually do anything to make software like WebP secure. Improving fuzzers and sandboxing might.
    - est31 3y ago
      > realistically new greenfield projects started today will likely take 10+ years to become widely used, if they do at all. I'm pretty sure that even now a lot speaks against using rust for greenfield projects precisely for that reason: few people want to integrate Rust into their build chain. You basically always have to have a compiler that's 1 release old or otherwise you cannot compile new Rust software like the very widely used time crate. If you are a new and unproven format, do you really want to bear that hit? You could make two implementations, one in C and one in Rust, but that will mean you spread your probably quite scarce engineers over two projects.
      - kentonv 3y ago
        Heh. Well, speaking as the lead engineer of a large C++ systems project that sadly started a liiiiitle bit to early to use Rust (the Cloudflare Workers runtime), I'd say our attitude is the other way around: We basically refuse to bring in any kind of C/C++ dependency unless it's something used in Chrome (implying they've vetted it). We are much more willing to bring in Rust dependencies, even though they're harder for us to invoke due to the language barrier.
        Yeroc 3y ago
        That's great, but the fact that the author of this article didn't mention memory safe languages is disturbing and an indication that not everyone is aware!
        albntomat0 3y ago
        The author is the former lead of Google Project Zero, and the article is an in depth look at a low level bug. He’s certainly aware of memory safe programming.
        est31 3y ago
        That's a really good policy, and what I said above does not reflect my private opinion but the opinions of a lot of people that decoder projects target. You are in a way more controlled environment. For dav1d I heard that one of the reasons why C was chosen was precisely this portability concern. format decoders are usually quite low level components and can get integrated into all sorts of environments. I'm sure there is someone out there who made a visual studio project with a 3 year old VS version with dav1d inside for some embedded project. For such devs, Rust is a way harder sell.
- est31 3y ago
  A rewrite of a webp decoder into Rust already exists (image-rs has a decoder for webp). I'm sure there is some polishing needed but it's nothing a company the size of Google can't afford.
  - Yeroc 3y ago
    Unfortunately, the readme for image-rs indicates that webp support is provided via the libwebp C library!
    - tedunangst 3y ago
      Only for encoding.
    - est31 3y ago
      That's for the encoding part. The 0day we are talking about was in the webp decoder, and decoders generally are the riskier component compared to encoders. I'm not sure if Chrome ships with the webp encoder at all.
- skitter 3y ago
  Mozilla has an interesting sandboxing strategy: They compile some of the C/C++ parts of Firefox (e.g. the ogg parser) to Wasm and then back to C. Because Wasm is memory safe, the resulting C is too.

by Yeroc 3y ago

Yes and Google Chrome has invested heavily in sandboxing and still had to ship this as a high-priority fix. I'd say sandboxing in conjunction with memory-safe languages is the future.

kentonv 3y ago

The problem is that rewriting existing code into a memory-safe language is a huge investment -- and realistically the world depends on a lot of code built over many decades that cannot be rewritten overnight. Consider that Mozilla created Rust specifically so they could rewrite their browser in it, yet still only a small fraction of Firefox code is Rust today -- much more is still C/C++. Realistically we're going to have a lot of heavily used C/C++ code forever. The singularity will come before we can replace it all. The nice thing about sandboxing and fuzzing can be applied to existing code.

Yeroc 3y ago
Yes, but sandboxing and fuzzing are insufficient. As pointed out in the article Google had been fuzzing this library and it didn't find the issue. They even tweaked the fuzzing after this issue was found to specifically target the area of the vulnerability and it apparently still didn't trigger the issue. Google Chrome also implements sandboxing and many areas. It's not feasible everywhere. So for new code / libraries we should default to a memory-safe language.
- kentonv 3y ago
  I think almost everyone agrees new greenfield projects should not choose C/C++, now that Rust has matured enough and covers essentially the same use cases. But realistically that only solves a tiny fraction of the problem, since realistically new greenfield projects started today will likely take 10+ years to become widely used, if they do at all. WebP was written at a time when C/C++ was still the only viable language in which to write an image compression library. Saying "things like this should be written in Rust!" just doesn't actually do anything to make software like WebP secure. Improving fuzzers and sandboxing might.
  - est31 3y ago
    > realistically new greenfield projects started today will likely take 10+ years to become widely used, if they do at all. I'm pretty sure that even now a lot speaks against using rust for greenfield projects precisely for that reason: few people want to integrate Rust into their build chain. You basically always have to have a compiler that's 1 release old or otherwise you cannot compile new Rust software like the very widely used time crate. If you are a new and unproven format, do you really want to bear that hit? You could make two implementations, one in C and one in Rust, but that will mean you spread your probably quite scarce engineers over two projects.
    - kentonv 3y ago
      Heh. Well, speaking as the lead engineer of a large C++ systems project that sadly started a liiiiitle bit to early to use Rust (the Cloudflare Workers runtime), I'd say our attitude is the other way around: We basically refuse to bring in any kind of C/C++ dependency unless it's something used in Chrome (implying they've vetted it). We are much more willing to bring in Rust dependencies, even though they're harder for us to invoke due to the language barrier.
      - Yeroc 3y ago
        That's great, but the fact that the author of this article didn't mention memory safe languages is disturbing and an indication that not everyone is aware!
        albntomat0 3y ago
        The author is the former lead of Google Project Zero, and the article is an in depth look at a low level bug. He’s certainly aware of memory safe programming.
      - est31 3y ago
        That's a really good policy, and what I said above does not reflect my private opinion but the opinions of a lot of people that decoder projects target. You are in a way more controlled environment. For dav1d I heard that one of the reasons why C was chosen was precisely this portability concern. format decoders are usually quite low level components and can get integrated into all sorts of environments. I'm sure there is someone out there who made a visual studio project with a 3 year old VS version with dav1d inside for some embedded project. For such devs, Rust is a way harder sell.
est31 3y ago
A rewrite of a webp decoder into Rust already exists (image-rs has a decoder for webp). I'm sure there is some polishing needed but it's nothing a company the size of Google can't afford.
- Yeroc 3y ago
  Unfortunately, the readme for image-rs indicates that webp support is provided via the libwebp C library!
  - tedunangst 3y ago
    Only for encoding.
  - est31 3y ago
    That's for the encoding part. The 0day we are talking about was in the webp decoder, and decoders generally are the riskier component compared to encoders. I'm not sure if Chrome ships with the webp encoder at all.
skitter 3y ago
Mozilla has an interesting sandboxing strategy: They compile some of the C/C++ parts of Firefox (e.g. the ogg parser) to Wasm and then back to C. Because Wasm is memory safe, the resulting C is too.