Live data from Hacker News

How memory safety CVEs differ between Rust and C/C++

kobzol.github.io

81–90 of 270 posts

Re: How memory safety CVEs differ between Rust and C/C++

#81
post #52

I'm not sure i think those situations are comparable. If a rust func is taking an Option , its essentially advertising that it can handle None values. That feels quite a bit different from giving a c function a null pointer and having it freak out.

But it isn't different, that's Tony Hoare's Billion Dollar Mistake.

It's absolutely different: “I call it my billion-dollar mistake. It was the invention of the null reference in 1965. At that time, I was designing the first comprehensive type system for references in an object oriented language (ALGOL W). My goal was to ensure that all use of references should be absolutely safe, with checking performed automatically by the compiler. But I couldn't resist the temptation to put in a null reference, simply because it was so easy to implement. This has led to innumerable errors, vulnerabilities, and system crashes, which have probably caused a billion dollars of pain and damage in the last forty years.”

His mistake was making _all_ reference taking functions also accept null. In Rust functions opt into None | Some

This comes up with C# which must have default(T) so references default to null. In Rust there is no general default(T) that must always resolve

Re: How memory safety CVEs differ between Rust and C/C++

#82
post #29

Is it only me that would have expected curl_getenv() to have an assert that it's argument isn't NULL? I know this doesn't stop runtime problems in release builds, but i'd have thought this sort of simple precondition check would help users find problems in their library useage. It's not going to stop you passing a non-terminated string, or other such invalid input though, which is I guess more the point, that it's to…

In addition to an assert, a 'nonnull' attribute on compilers that support it seems like a good idea.

Re: How memory safety CVEs differ between Rust and C/C++

#83
post #77

Earlier quoted context omitted.

Rust's standard library is incredibly thin (intentionally so). As a result, you need to use the crate ecosystem. This comes with some downsides. 1. Each crate you depend on generally comes with dozens of its own dependencies. 2. A large number of crates have few downloads. You can use blessed.rs to try an find "trusted" dependencies. 3. Cargo comes with "build.rs" for compile time code execution. Basically, your code…

I think none of this is special to Rust vs C++, except #4, because C++ doesn't have an equivalent

Most dependencies in the C/C++ world come with fewer dependencies of their own (at least, an order of magnitude fewer than the average rust dependency).

Perhaps a Makefile could be considered arbitrary code execution, but we've been running Makefiles for 50 years and we haven't had the supply chain issues we see in NPM, etc.

Supply chain risk was always considered in the C/C++ world... think back to Ken Thompson's 1984 paper "Reflections on Trusting Trust" where he questioned if you could even trust your compiler.

Perhaps the main difference between the Rust and C/C++ world is less about the tooling or languages, but more cultural? I don't know, just something to think about.

Re: How memory safety CVEs differ between Rust and C/C++

#84

Just want to remind everyone that only 1% of vulnerabilities are memory related in the average Joe's code. And only 20% of memory related bugs are use-after-free which the borrow checker fighting is for. And 100% of the use-after-free exploits were to gain admin rights on an already hacked Windows (all windows) computer. So for the vast majority of people the borrow checker adds nothing. The vast majority of memory s…

Any sources for these numbers?

https://www.youtube.com/watch?v=r7l0Rq9E8MY&t=2s

Re: How memory safety CVEs differ between Rust and C/C++

#85
post #81

Earlier quoted context omitted.

But it isn't different, that's Tony Hoare's Billion Dollar Mistake.

It's absolutely different: “I call it my billion-dollar mistake. It was the invention of the null reference in 1965. At that time, I was designing the first comprehensive type system for references in an object oriented language (ALGOL W). My goal was to ensure that all use of references should be absolutely safe, with checking performed automatically by the compiler. But I couldn't resist the temptation to put in a…

My contrast was to "That feels quite a bit different". The type system in C only has Tony's nullable references, you can't say that you don't mean that because it wasn't your choice to make, it's like if some C programmers say obviously they don't mean zero when they take an integer - too bad, C doesn't have the non-zero integers (Rust does, NonZeroI32 for example is the signed 32-bit integers except zero)

Re: How memory safety CVEs differ between Rust and C/C++

#86

Earlier quoted context omitted.

> supply chain risk how is rust special in this regard?

Rust's standard library is incredibly thin (intentionally so). As a result, you need to use the crate ecosystem. This comes with some downsides. 1. Each crate you depend on generally comes with dozens of its own dependencies. 2. A large number of crates have few downloads. You can use blessed.rs to try an find "trusted" dependencies. 3. Cargo comes with "build.rs" for compile time code execution. Basically, your code…

again, I don't really see how 1 and 2 are rust specific; compared to c -- sure, but it's seems unfair: the type of rust software that needs a bunch of random dependencies usually wouldn't even exist in c in the first place; if it would, then it's more of a software quality problem than security

even 4 -- fuck microsoft of course, but other than that: you always need some sort of an account to publish stuff

Re: How memory safety CVEs differ between Rust and C/C++

#87

Earlier quoted context omitted.

I agree about Rust gaining ground but using the argument that it got 10% faster due to Rust is not really that useful. If they rewrote it in C++ again, they would have most likely got the same result because they got a chance to fix a design that might not have been most optimal.

> If they rewrote it in C++ again, they would have most likely got the same result because they got a chance to fix a design that might not have been most optimal. This speculation has been offered every time. It's not crazy to think this might be true, but it's also not crazy to think that if C++ keeps leaving performance on the table and Rust doesn't that adds up for real projects. When Titus wrote "ABI: Now or Nev…

Until Rust has equal meta-programming support to C++ it's always going to be "slower". That's why people always say this because it's always true there is nothing Rust can do C++ can't but there is quite a few things you can do in C++ but not in Rust.

Realistically the difference doesn't matter much and if you're writing code that must be as fast as possible your writing unsafe Rust that looks a lot more like C/C++ then anything Rust.

Re: How memory safety CVEs differ between Rust and C/C++

#88

Earlier quoted context omitted.

In languages that don't have a culture of deep dependency trees managed with good tooling, supply chain attacks are perceived as being more difficult or rarer. That may or may not be true. But it is a concern in any case. Rust could have had namespaces to decrease namesquatting. The "no deps younger than N days" thing will help some. Those with this perception would prefer a large stdlib that is well vetted or that t…

> austral thanks, can't believe the idea isn't more mainstream -- I've never thought dependency safety could be a thing

In rust if you can verify a dependency is no_std with no unsafe code and that all of it's dependencies are the same, then it can't get to libc or the kernel syscalls. So any privilege it works with is something you passed it. But that amounts to writing everything yourself in practice.

Re: How memory safety CVEs differ between Rust and C/C++

#90
Bjarne Stroustrup was recently interviewed by Ryan Peterman^1

1. https://youtu.be/U46fJ2bJ-co?t=2780

and Ryan asked Bjarne about memory safety. Bjarne brushes it off and says that in almost all cases where we see memory safety issues, they are either

1. Being written in C style C++ and not using "Modern C++" 2. Being written in C

He then goes on to say say that Modern C++ and where it is necessary, hardened libraries, go a long way to making these problems non issues. I'm not a C++ guy, so how much of this is true? What do the C++ developers think about this?

I've postd the whole message if people would like to read. It's about 46minutes into the video

Ryan: One thing that I think C++ is uh infamous for is kind of like memory safety issues or kind of foot guns that exist there.

Bjarne: I'm so tired of that. Um I haven't had those problems for years. Um, and somebody did a a study of the obvious problems with buffer overflows and um people hacking in using that kind of stuff and uh almost all of the uh these cases when people writing C style code or in C and uh Herb Server has a a talk with with actual numbers and they they are quite significant. It's it's sort of that kind of problems more than 90% are for people that don't write modern C++. They they use raw pointers to pass things around without um the number of elements. No fat pointers, no spans. um you you have them in C++. You can use them. You can use uh vectors. We have hardened libraries. Everybody has hardened libraries that that does the runtime checking. Uh Apple has it. Google has it. Microsoft has it. It's just not standard till now. C++ 26 has a hardened option that are standard. uh and the work I'm doing on profiles will give you a way of guaranteeing that you don't do the stupid things. Um so anyway, uh fundamentally theoretically the problem was solved many years ago and people just do what they've always done and get the problems they've always had. And uh that makes me sad and uh it's one of the things that makes me work on uh coding guidelines and on enforced profiles and on education. I mean education is one way to solve the problem. Is there a way to get the compiler to just prevent people from doing all those risky things? And is that enabled by default in modern C++ today? No, but it should be. I'm proposing that for C++ 29. Uh the simpler versions of that should have been in in in uh C++ 26, but there are still a lot of people even in the C++ standards committee that are very devoted to uh their old code and their old ways of doing things. Um there's people who says you should only standardize what is common in industry. But when the bugs are common in industry, you should do something else. The standards committee is a a topic I

Post reply on HN