Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

kobzol.github.io

Post reply on HN
Print view View original

71–80 of 270 posts

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

#71

Post by bitbasher »

anuramat wrote: post #67
bitbasher wrote: post #62

Memory safety is a concern, but there are many solutions that don't include Rust. Rust is certainly one solution, though. However, Rust seems to trade memory safety vulnerabilities for supply chain risk.

> 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 (or your dependencies) can run arbitrary code when it first gets compiled.

4. A Github account is required to publish crates to crates.io (this sucks if you don't want to be locked in to another Microsoft system).

These are just a few of the issues I have had with Rust before switching off it.

edit:

Point #4 is personal for me. I have multiple crates published on crates.io and I cannot log in and manage them because I deleted my GitHub account a long time ago. I wonder if someone could create a GitHub account using my name and claim ownership of them...

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

#72

Post by anuramat »

galangalalgol wrote: post #68
anuramat wrote: post #67

Earlier quoted context omitted.

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

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

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

#73

Post by mk89 »

john_strinlai wrote: post #42

> Because sometimes I see people online who compare the number of CVEs in Rust and C/C++ software, [...] a rule of thumb i follow is that the second someone starts comparing or talking about the number of CVEs, i just ignore whatever they say next. its hard to think of a more useless metric than "number of CVEs", especially now. (edit: the people disagreeing are encouraged to share how you use "number of CVEs" to inf…

Oh no, you're in for a surprise.

"Especially now" all these infosec folks "need to get CVEs fixed because compliance/SOC2, etc" and they will be even more up your a*!

Something has to change with how compliance works. It is so outdated and crazy.

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

#74

Post by tialaramex »

bawolff wrote: 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.

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

#75

Post by dochtman »

bitbasher wrote: post #71
anuramat wrote: post #67

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…

> I wonder if someone could create a GitHub account using my name and claim ownership of them...

AIUI the crates are actually linked to the account via a different identifier, not directly to the username.

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

#76

Post by afdbcreid »

bitbasher wrote: post #71
anuramat wrote: post #67

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…

As for #4, you will probably be interested in https://github.com/rust-lang/crates.io/issues/326. The crates.io team wants this, but this is complex to implement and they're understaffed.

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

#77

Post by tcfhgj »

bitbasher wrote: post #71
anuramat wrote: post #67

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…

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

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

#78

Post by bitbasher »

afdbcreid wrote: post #76
bitbasher wrote: post #71

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…

As for #4, you will probably be interested in https://github.com/rust-lang/crates.io/issues/326 . The crates.io team wants this, but this is complex to implement and they're understaffed.

I've seen it, but it's from 2016. They have known about the issue for a 10+ years and haven't fixed it yet... seems unlikely to change!

Maybe some day though!

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

#79

Post by afdbcreid »

thegrim33 wrote: post #65

Really annoying when people take 50 year old C code and modern C++ code and just drop them into the same bucket and refer to them as if they're the same thing. The CURL example they give has multiple modern C++ solutions that accomplish the same thing without UB.

This doesn't matter to the post, because it is about culture, not about code.

And there are plenty of ways to cause UB with modern C++ idioms.

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

#80

Post by john_strinlai »

mk89 wrote: post #73
john_strinlai wrote: post #42

> Because sometimes I see people online who compare the number of CVEs in Rust and C/C++ software, [...] a rule of thumb i follow is that the second someone starts comparing or talking about the number of CVEs, i just ignore whatever they say next. its hard to think of a more useless metric than "number of CVEs", especially now. (edit: the people disagreeing are encouraged to share how you use "number of CVEs" to inf…

Oh no, you're in for a surprise. "Especially now" all these infosec folks "need to get CVEs fixed because compliance/SOC2, etc" and they will be even more up your a*! Something has to change with how compliance works. It is so outdated and crazy.

>all these infosec folks

i am an infosec folk (:

Post reply on HN