8 ms·

Not to be snarky, but my initial response to this was "Large project that uses language known for memory safety issues discovers that most of their security bug

Not to be snarky, but my initial response to this was "Large project that uses language known for memory safety issues discovers that most of their security bugs stem from memory safety issues". In a more serious note, I hope this motivates the Chromium team to invest more in Rust. While the other options sound like good "in the meantime" solutions, switching to a language that, at its core, is designed to prevent these sorts of issues would be a huge benefit to society as a whole considering that Chromium is the most popular browser engine in the world.

rosstex 6y ago
70% of security defects in memory-safe languages are probably also memory safety problems.
- _bxg1 6y ago
  That doesn't make any sense at all
  - robobro 6y ago
    The world doesn't make sense. That's why we humans suffer.
  - rosstex 6y ago
    please laugh i'm trying my best
    - antonvs 6y ago
      70% of all failed jokes on HN were best efforts. But not this one.
      - nullc 6y ago
        70% of all failed jokes on HN are due to memory safety problems.
        stock_toaster 6y ago
        young people are duck typed. anything is valid input. middle age is a time of strict typing. old age is all dangling references and memory safety issues.
  - saagarjha 6y ago
    My guess is that the commenter is trying to say that security issues safe languages are probably a result of calling into unsafe code or a bugs in a runtime written in an unsafe language.
  - scottlamb 6y ago
    >> 70% of security defects in memory-safe languages are probably also memory safety problems. > That doesn't make any sense at all I'm sure it's not true—70% is way too high—but the real number isn't 0% as you might expect. In particular, (most? all?) non-Rust languages that claim or appear to be memory-safe can have data races. In Go for example, those can be exploitable. [1] And Rust is memory-safe...in safe code, with a bug-free compiler. Real programs have some unsafe code in their transitive dependencies and are compiled with the real, buggy compiler. [2] The percentage of security bugs in Rust code that are due to memory safety problems is more than 0%. [1] https://blog.stalkr.net/2015/04/golang-data-races-to-break-memory-safety.html https://blog.stalkr.net/2015/04/golang-data-races-to-break-m... [2] https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3A%22I-unsound+%F0%9F%92%A5%22 https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Ais...
    - jkelleyrtp 6y ago
      Not to say they don’t exist or haven’t been reported, but many of the unsound issues on github for Rust don’t seem to hold water. They all seem to misbehave on a single nightly build, affect only a very narrow and unsupported target group, be related to a bug in a unsupported release of LLVM, or simply aren’t reproducible. I think the percentage of security bugs in Rust related to memory safety, based off that list, is _effectively_ 0%. I can’t find an issue in the list that seems like it would impact Rust programs that people write today or on targets that people deploy Rust code where memory safety matters.
      - nindalf 6y ago
        That probably reflects the higher standards in the Rust ecosystem. I remember when there was a big issue about “Pin is unsound”. Judging by how seriously people were taking it, it seemed like it was the next Heartbleed. Turned out that it was unsound only in a very contrived example. Still, it was cool that it was fixed so quickly.
      - scottlamb 6y ago
        Most of the currently open ones may be nightly-only and/or mostly theoretical, but there was recently a bad borrow checker bug for example: https://blog.rust-lang.org/2020/02/27/Rust-1.41.1.html#a-soundness-hole-in-checking-static-items https://blog.rust-lang.org/2020/02/27/Rust-1.41.1.html#a-sou... I don't think soundness/security flaws due to compiler bugs are common, but they qualitatively can happen. I think that might be getting forgotten when folks are puzzled about the idea of memory safety bugs in memory-safe languages.
scottlamb 6y ago
But "large project that uses language known for memory safety issues" describes a lot of important software today. It's not like there are tons of practical language options for memory-safe high-performance code, and there were essentially none when many such projects started. So while this may be unsurprising to those paying attention to Rust and memory safety, it's still relevant to a lot of software and a great confirmation of Rust's importance.
- networkimprov 6y ago
  Java is mature and regarded as high performance, even if it is a memory glutton.
  - jolux 6y ago
    Rust has significantly less overhead than Java
    - lmm 6y ago
      Like a factor of 2 at best. Nice to have, but not the difference between usable and unusable.
      - scottlamb 6y ago
        Do you really think at any time in Chrome's lifespan that its developers would accept a decision that is so foundational (aka hard to reverse) and slows everything down by a factor of 2? I don't. If they had, I don't think it would be the most popular browser today, and arguably it wouldn't even still be around. IIRC, speed was a major selling point when it was released. (I also don't really think Java is that much slower but substitute a more precise guess and my statement stands. And I think Java and other GCed languages really do use ~2X as much RAM which is also unacceptable.)
        lmm 6y ago
        The speed of Chrome's from-scratch JavaScript engine was a major selling point when released, yes. But that speed came from a lot of places - after all, competing JavaScript engines were also written in C++, and in particular areas V8 was thousands of times faster than them. Using Java over C++ would have meant a factor of 2 up-front performance cost. But it would also have meant significantly less time debugging, easier testing, faster iteration, better automated refactoring support... all of which would have added up to being able to spend more development effort finding the kind of algorithmic improvements that give you those 1000x speedups. I'm not at all convinced that the end result would have been slower.
ridiculous_fish 6y ago
Has there been any work on how to leverage Rust's strengths for a GC language implementation? For example, Rust assumes unique ownership for mutable values; how do you express that the value is also reachable by the GC?
- saagarjha 6y ago
  I’m not sure I follow. Are you suggesting the addition of multiple mutable ownership of values to Rust, managed by a garbage collector?
  - ridiculous_fish 6y ago
    No, I am talking about writing Rust code that refers to objects on a GC-managed heap. For example, assume v8-ish semantics: let mut cell = allocate(0.0); let counter : &mut f64 = cell.as_mut_ref(); *counter += 1; stuff(); *counter -= 1; Here `stuff()` may trigger further allocations which result in moving `cell`, leaving `counter` dangling.
    - saagarjha 6y ago
      Ah. I am not a Rust expert but I think the language might actually support this sort of construct (though it might be inefficient to implement), as IIRC if you want something to stay at a fixed place in memory you need to “pin” it there.
    - pirocks 6y ago
      Surely they way most gcs achieve this is by asking you to tell the gc when you aquire a reference to an object, and tell it again when you no longer need it. You could do that with a custom implementation of drop in rust.
- Falell 6y ago
  This isn't really directly related to your question, but I recall hearing that in Servo and Firefox, the usage of Rust is limited as it gets close to the DOM specifically because of interactions with the JS engine and its separate garbage collector, which Rust does not understand. Without any more specific knowledge, I bet the way a generational garbage collector moves data around really messes with Rust's view of the world...
fabrice_d 6y ago
See https://chromium-review.googlesource.com/q/project:experimental/chromium/src+branch:refs/wip/rust-experimental-branch https://chromium-review.googlesource.com/q/project:experimen... for some work to integrate Rust in chromium
petre 6y ago
The "large project" part pretty much explains why the don't just rewrite it in Rust. It might be easier to audit the source code and rewrite the offending code, write C++ libraries to mitigate the issue or both. Also see: https://news.ycombinator.com/item?id=23059477 https://news.ycombinator.com/item?id=23059477
- the_why_of_y 6y ago
  > It might be easier to audit the source code and rewrite the offending code What do you think Chromium developers have been doing for the last 10 years, sitting on their hands? My understanding is that the main reason why Google OSS-Fuzz exists is Chromium. The problem with this approach is that it evidently (see OP) doesn't work to find all the bugs before release.

rosstex 6y ago

70% of security defects in memory-safe languages are probably also memory safety problems.

_bxg1 6y ago
That doesn't make any sense at all
- robobro 6y ago
  The world doesn't make sense. That's why we humans suffer.
- rosstex 6y ago
  please laugh i'm trying my best
  - antonvs 6y ago
    70% of all failed jokes on HN were best efforts. But not this one.
    - nullc 6y ago
      70% of all failed jokes on HN are due to memory safety problems.
      - stock_toaster 6y ago
        young people are duck typed. anything is valid input. middle age is a time of strict typing. old age is all dangling references and memory safety issues.
- saagarjha 6y ago
  My guess is that the commenter is trying to say that security issues safe languages are probably a result of calling into unsafe code or a bugs in a runtime written in an unsafe language.
- scottlamb 6y ago
  >> 70% of security defects in memory-safe languages are probably also memory safety problems. > That doesn't make any sense at all I'm sure it's not true—70% is way too high—but the real number isn't 0% as you might expect. In particular, (most? all?) non-Rust languages that claim or appear to be memory-safe can have data races. In Go for example, those can be exploitable. [1] And Rust is memory-safe...in safe code, with a bug-free compiler. Real programs have some unsafe code in their transitive dependencies and are compiled with the real, buggy compiler. [2] The percentage of security bugs in Rust code that are due to memory safety problems is more than 0%. [1] https://blog.stalkr.net/2015/04/golang-data-races-to-break-memory-safety.html https://blog.stalkr.net/2015/04/golang-data-races-to-break-m... [2] https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3A%22I-unsound+%F0%9F%92%A5%22 https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Ais...
  - jkelleyrtp 6y ago
    Not to say they don’t exist or haven’t been reported, but many of the unsound issues on github for Rust don’t seem to hold water. They all seem to misbehave on a single nightly build, affect only a very narrow and unsupported target group, be related to a bug in a unsupported release of LLVM, or simply aren’t reproducible. I think the percentage of security bugs in Rust related to memory safety, based off that list, is _effectively_ 0%. I can’t find an issue in the list that seems like it would impact Rust programs that people write today or on targets that people deploy Rust code where memory safety matters.
    - nindalf 6y ago
      That probably reflects the higher standards in the Rust ecosystem. I remember when there was a big issue about “Pin is unsound”. Judging by how seriously people were taking it, it seemed like it was the next Heartbleed. Turned out that it was unsound only in a very contrived example. Still, it was cool that it was fixed so quickly.
    - scottlamb 6y ago
      Most of the currently open ones may be nightly-only and/or mostly theoretical, but there was recently a bad borrow checker bug for example: https://blog.rust-lang.org/2020/02/27/Rust-1.41.1.html#a-soundness-hole-in-checking-static-items https://blog.rust-lang.org/2020/02/27/Rust-1.41.1.html#a-sou... I don't think soundness/security flaws due to compiler bugs are common, but they qualitatively can happen. I think that might be getting forgotten when folks are puzzled about the idea of memory safety bugs in memory-safe languages.

scottlamb 6y ago

But "large project that uses language known for memory safety issues" describes a lot of important software today. It's not like there are tons of practical language options for memory-safe high-performance code, and there were essentially none when many such projects started. So while this may be unsurprising to those paying attention to Rust and memory safety, it's still relevant to a lot of software and a great confirmation of Rust's importance.

networkimprov 6y ago
Java is mature and regarded as high performance, even if it is a memory glutton.
- jolux 6y ago
  Rust has significantly less overhead than Java
  - lmm 6y ago
    Like a factor of 2 at best. Nice to have, but not the difference between usable and unusable.
    - scottlamb 6y ago
      Do you really think at any time in Chrome's lifespan that its developers would accept a decision that is so foundational (aka hard to reverse) and slows everything down by a factor of 2? I don't. If they had, I don't think it would be the most popular browser today, and arguably it wouldn't even still be around. IIRC, speed was a major selling point when it was released. (I also don't really think Java is that much slower but substitute a more precise guess and my statement stands. And I think Java and other GCed languages really do use ~2X as much RAM which is also unacceptable.)
      - lmm 6y ago
        The speed of Chrome's from-scratch JavaScript engine was a major selling point when released, yes. But that speed came from a lot of places - after all, competing JavaScript engines were also written in C++, and in particular areas V8 was thousands of times faster than them. Using Java over C++ would have meant a factor of 2 up-front performance cost. But it would also have meant significantly less time debugging, easier testing, faster iteration, better automated refactoring support... all of which would have added up to being able to spend more development effort finding the kind of algorithmic improvements that give you those 1000x speedups. I'm not at all convinced that the end result would have been slower.

ridiculous_fish 6y ago

Has there been any work on how to leverage Rust's strengths for a GC language implementation? For example, Rust assumes unique ownership for mutable values; how do you express that the value is also reachable by the GC?

saagarjha 6y ago
I’m not sure I follow. Are you suggesting the addition of multiple mutable ownership of values to Rust, managed by a garbage collector?
- ridiculous_fish 6y ago
  No, I am talking about writing Rust code that refers to objects on a GC-managed heap. For example, assume v8-ish semantics: let mut cell = allocate(0.0); let counter : &mut f64 = cell.as_mut_ref(); *counter += 1; stuff(); *counter -= 1; Here `stuff()` may trigger further allocations which result in moving `cell`, leaving `counter` dangling.
  - saagarjha 6y ago
    Ah. I am not a Rust expert but I think the language might actually support this sort of construct (though it might be inefficient to implement), as IIRC if you want something to stay at a fixed place in memory you need to “pin” it there.
  - pirocks 6y ago
    Surely they way most gcs achieve this is by asking you to tell the gc when you aquire a reference to an object, and tell it again when you no longer need it. You could do that with a custom implementation of drop in rust.
Falell 6y ago
This isn't really directly related to your question, but I recall hearing that in Servo and Firefox, the usage of Rust is limited as it gets close to the DOM specifically because of interactions with the JS engine and its separate garbage collector, which Rust does not understand. Without any more specific knowledge, I bet the way a generational garbage collector moves data around really messes with Rust's view of the world...

fabrice_d 6y ago

See https://chromium-review.googlesource.com/q/project:experimental/chromium/src+branch:refs/wip/rust-experimental-branch https://chromium-review.googlesource.com/q/project:experimen... for some work to integrate Rust in chromium

petre 6y ago

The "large project" part pretty much explains why the don't just rewrite it in Rust. It might be easier to audit the source code and rewrite the offending code, write C++ libraries to mitigate the issue or both. Also see: https://news.ycombinator.com/item?id=23059477 https://news.ycombinator.com/item?id=23059477

the_why_of_y 6y ago
> It might be easier to audit the source code and rewrite the offending code What do you think Chromium developers have been doing for the last 10 years, sitting on their hands? My understanding is that the main reason why Google OSS-Fuzz exists is Chromium. The problem with this approach is that it evidently (see OP) doesn't work to find all the bugs before release.