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

111–120 of 270 posts

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

#111

Post by okanat »

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…

> Rust's standard library is incredibly thin (intentionally so). As a result, you need to use the crate ecosystem. This comes with some downsides.

This is no different than C++. C++ standard library made so many compromises in the name of ABI compatibility almost none of the library is actually usable for any use case. So people start to quickly add things like boost, abseil, folly, Qt, asio, imgui, doctest etc. There are millions of small libraries everywhere too!

Their CMakeLists files or conan packages also execute random commands and in the case of supply chain compromise they are as vulnerable as Rust. Actually CMake is so complicated that one can hide an exploit a bit better than build.rs.

I don't think it is a good thing either way and both toolchains should implement ways to limit execution and isolate code generation. For the packages we also need to see stronger ownership and signing guarantees. Maybe even a domain-based validation system with TXT-keys against takeovers. Allowing random people to just register and typosquat packages is not a good idea.

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

#112

Post by mk89 »

john_strinlai wrote: post #80
mk89 wrote: post #73

Earlier quoted context omitted.

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 (:

Well you're a bit different then...

In my experience it is becoming basically ridiculous that we disallow compliance based on a number of cve, their level, etc. It's just a checkbox, but it has nothing to do with security.

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

#113

Post by blueg3 »

gkfasdfasdf wrote: post #82
cesaref wrote: 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.

If you use the nonnull attribute, the assertion will be optimized away.

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

#114

Post by jamesfinlayson »

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.

Yep, at work my team's vulnerability dashboard constantly shows hundreds of critical and high vulnerabilities. Fortunately/unfortunately, 99% of these issues are for Javascript dependencies in websites that are not server-side rendered... so we look bad, even though we have no exposure to most of these vulnerabilities.

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

#115

Post by bannable »

tialaramex wrote: post #49
afdbcreid wrote: post #44

Earlier quoted context omitted.

You said > I'm not convinced this is true. But it is. It is true that Rust libraries could take this position of "any API misuse causing vulnerability is a CVE" more to the extreme, currently it is applied to memory safety but it could be applied to panics as well. However it is still true that pretty much all Rust libraries treat API misuses that cause UB as a CVE, and pretty much no C/C++ library does that, and tha…

> Rest assured that you are much more likely to hit a miscompilation in your compiler's backend, and that it is much harder to detect. The LLVM provenance bug is a really nice example. The Rust which tickles this bug (LLVM emits nonsense, claiming that two integers a and b are different but then calculating that a - b == 0...) is fairly clear, you wouldn't write it by accident but it's obvious what it should do, and…

What is the "LLVM provenance bug"?

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

#116

Post by dundarious »

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?

It's not special in this regard in the language, or even especially so in the available tooling. Nevertheless, the culture in rust is to add many many dependencies. I occasionally use self-professed "small, modern" CLI tools that use ~400 crates (e.g., interactive podcast downloader).

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

#117

Post by lmm »

jstimpfle wrote: post #108
dwattttt wrote: post #104

Earlier quoted context omitted.

An assertion is an app crashing on a violation. The problem is when it's not guaranteed to crash, and instead does something very wrong.

A bug is a bug even when it doesn't clearly manifest itself 100% of the time, and furthermore it is pretty much guaranteed that NULL dereference crashes with segfault in practice, only not for the people playing theoretic games whose essence of life is finding gotchas where it maybe isn't so and then feeling smarter than everyone else. But it's >> 99.9% true that this will just crash even though it's acshually UB, na…

> it's >> 99.9% true that this will just crash even though it's acshually UB, nasal demons and so forth.

Is it though? Linux saw enough bugs from that kind of issue that they now build with -fno-delete-null-pointer-checks and accept the (supposed) performance penalty.

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

#118

Post by tialaramex »

bannable wrote: post #115
tialaramex wrote: post #49

Earlier quoted context omitted.

> Rest assured that you are much more likely to hit a miscompilation in your compiler's backend, and that it is much harder to detect. The LLVM provenance bug is a really nice example. The Rust which tickles this bug (LLVM emits nonsense, claiming that two integers a and b are different but then calculating that a - b == 0...) is fairly clear, you wouldn't write it by accident but it's obvious what it should do, and…

What is the "LLVM provenance bug"?

https://github.com/llvm/llvm-project/issues/45725

Are you familiar with pointer provenance ? This gets very deep, very fast, so if you don't know and don't want to know I can't help you, but if you do want to know try maybe: https://www.ralfj.de/blog/2018/07/24/pointers-and-bytes.html

So e.g. if we make a pointer to thing A, which we then destroy, and then for a pointer to thing B, and then we compare these pointers, even if the address which will be the only bits making up this pointer in hardware was identical, a language could choose to say these pointers are not the same (Rust says they compare equal but that's up to Rust). LLVM is equipped to do this optimisation. So far, not a bug, though perhaps not what you expected...

However everybody is pretty sure that we don't want provenance for other value types. It's troublesome for pointers but we're used to it and it unlocks important optimisations, but for every other value type it's just extra trouble. So Rust's provenance model says only pointers have provenance, and proposals for C and C++ likewise. If we ask for the address from a pointer, making it into just an integer, it should not longer have provenance.

But, LLVM doesn't really track whether a value "is" pointer or not per se, so it ends up applying that "they're not equal" optimisation to the integers we've made from pointers, even though the integers are definitely equal and we're about to do a subtraction to prove it. Bang.

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

#119

Post by cesarb »

tialaramex wrote: post #43
ghosty141 wrote: post #24

Earlier quoted context omitted.

> but Rust is pushing into domains where C and C++ dominated in the past. I think it's also a big sign that the linux kernel adopted rust and not c++. (only for small parts but still)

A not inconsiderable part of why is that Rust for Linux did the work. When C++ people say they think there should be C++ in Linux, their proposal usually begins by proposing that it "should" be possible to just compile Linux as C++ software. This doesn't work because C isn't just "C++ but old", and they rapidly lose interest. Which of course also feeds into Linus' semi-fair claim that not allowing C++ keeps out the l…

> their proposal usually begins by proposing that it "should" be possible to just compile Linux as C++ software

That has already been done in the past. Quoting the FAQ:

"[...] the kernel was once modified to be compiled under g++. That lasted for a few revisions. People complained about the performance drop. It turned out that compiling a piece of C code with g++ would give you worse code. It shouldn't have made a difference, but it did. Been there, done that."

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

#120

Post by tialaramex »

tick_tock_tick wrote: post #87
tialaramex wrote: post #46

Earlier quoted context omitted.

> 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++ t…

> Until Rust has equal meta-programming support to C++ it's always going to be "slower".

I don't think that makes a lot of sense even theoretically because of e.g. aliasing, but it doesn't matter because as I said, C++ chooses to be slower, Titus gives a number of examples where we know how to do X fast, and that's how Rust does X - in theory C++ could X the same way, but none of the three C++ compilers people actually use do it, because they picked wrong and then froze their ABI and won't thaw it.

Post reply on HN