7 ms·
70% of security defects in memory-safe languages are probably also memory safety problems.
by rosstex 6y ago
70% of security defects in memory-safe languages are probably also memory safety problems.
- _bxg1 6y agoThat doesn't make any sense at all
- robobro 6y agoThe world doesn't make sense. That's why we humans suffer.
- rosstex 6y agoplease laugh i'm trying my best
- antonvs 6y ago70% of all failed jokes on HN were best efforts. But not this one.
- nullc 6y ago70% of all failed jokes on HN are due to memory safety problems.
- stock_toaster 6y agoyoung 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 agoMy 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 agoNot 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 agoThat 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 agoMost 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.