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

141–150 of 270 posts

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

#141

Post by jiggawatts »

jamesfinlayson wrote: post #114
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.

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.

Just yesterday I made myself a NuGet package analyzer tool -- okay fine, I vibe coded it -- that has convenient buttons for filtering out client-side packages, test projects, and dev-time tooling like Aspire.NET.

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

#142

Post by uecker »

There can be made very good arguments why C is less safe than Rust, but null pointer dereferences which are perfectly safe everywhere except on weird platforms (and usually could be made safe even there by turning on a compiler flag) seems a very misleading argument.

And as as the Cloudflare incident showed, a Rust unwrap can have equally bad consequences. (or as Ariane 5 showed, a safe overflow in Ada can have explosive consequences)

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

#143

Post by lmm »

uecker wrote: post #138
lmm wrote: post #117

Earlier quoted context omitted.

> 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.

The kernel is perhaps bit special. In the past they had bugs such as first derferencing and then checking for null and weird possibilities to map the zero page. But today I am not convinced this is really needed. In general on a system where you trap when accessing the zero page, this optimization should be safe and a null pointer dereferences should (safely) trap.

> In general on a system where you trap when accessing the zero page, this optimization should be safe and a null pointer dereferences should (safely) trap.

If you mean that C compiler writers "should" prioritise sanity over high scores on microbenchmarks, then I agree. However in practice they do not and this optimization is not remotely safe.

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

#144

Post by uecker »

lmm wrote: post #143
uecker wrote: post #138

Earlier quoted context omitted.

The kernel is perhaps bit special. In the past they had bugs such as first derferencing and then checking for null and weird possibilities to map the zero page. But today I am not convinced this is really needed. In general on a system where you trap when accessing the zero page, this optimization should be safe and a null pointer dereferences should (safely) trap.

> In general on a system where you trap when accessing the zero page, this optimization should be safe and a null pointer dereferences should (safely) trap. If you mean that C compiler writers "should" prioritise sanity over high scores on microbenchmarks, then I agree. However in practice they do not and this optimization is not remotely safe.

Do you have any evidence for this? On GCC it should be safe.

(EDIT: what is not safe is indexing into a null pointer. For this you need to be safe you need -fsanitize=null)

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

#145

Post by saghm »

thayne wrote: post #136
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…

> it's not possible to add a precondition without introducing a runtime overhead Indeed. Adding an assertion to a single function isn't a big deal, but if every function has to check all of it's arguments, that's going to add up. And even if you could have the assertion only in debug builds, that isn't enough unless you have a very exhaustive test suite, because an edge case could trigger undefined behavior in produc…

> In fact, the fact that the rust compiler adds runtime checks for array indexes if it can't prove the index is in bounds is a criticism some c programmers have of rust.

And the fact that after a half a century we're still debating how much we really need to care about U stuff like this when we get severe bugs in a major piece of software written in C seemingly every week is a criticism that pretty much all Rust programmers have of C.

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

#146

Post by saghm »

tialaramex wrote: post #74
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.

It seems like you're pretty fundamentally misunderstanding what the mistake is, because you have it backwards. Null is a problem because you can just use it like any other pointer without having to explicitly decide how to handle if it's null; Option does not have this problem because you have to explicitly decide how to handle if it's None. Even if you choose to crash if it's None, that's an explicit operation on an Option itself, not the underlying value. There's no equivalent way to force an explicit decision about handling null; it looks just like every other pointer, which means that the only way to avoid using it like one is to be really careful (which we have decades of empircal evidence showing might as well be impossible to do uniformly).

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

#147

Post by mk89 »

tptacek wrote: post #122
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.

Compliance != security. It's almost the natural enemy of security.

This is true, but security teams often work on tooling dedicated to reduce the n. of CVEs so that a company can keep compliance. That is in fact part of compliance itself to have an automated/reliable processo to tackle CVEs...

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

#148

Post by tptacek »

mk89 wrote: post #147
tptacek wrote: post #122

Earlier quoted context omitted.

Compliance != security. It's almost the natural enemy of security.

This is true, but security teams often work on tooling dedicated to reduce the n. of CVEs so that a company can keep compliance. That is in fact part of compliance itself to have an automated/reliable processo to tackle CVEs...

Which compliance regime are you referring to that cares about CVE counts as a metric?

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

#149

Post by saghm »

f33d5173 wrote: post #93
eptcyka wrote: post #61

Earlier quoted context omitted.

Ye, sure, but Rust won’t compile a `foo(std::ptr::null())`, if the function is defined as `fn foo(b: &Baz)`. C doesn’t get that luxury. That is the point of the article.

$ gcc -Wall -Werror -x c - :1:37: error: null passed to a callee that requires a non-null argument [-Werror,-Wnonnull] 1 | void f(int x[static 1]){}int main(){f(0);} | ^ ~ :1:12: note: callee declares array parameter as static here 1 | void f(int x[static 1]){}int main(){f(0);} | ^~~~~~~~~~~ 1 error generated. It can be done, though it usually isn't.

Can you do that with a dynamic array? If not, it's pretty severely limited (unless you mean that literally forbidding dynamic memory is usually not done, which I guess it's true outside of some embedded code but not a particularly meaningful statement).

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

#150

Post by mk89 »

mk89 wrote: post #112
john_strinlai wrote: post #80

Earlier quoted context omitted.

> 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.

Not sure about the downvote.

I'd like to know how a "critical CVE running in your software for 29 days" is acceptable from a security standpoint. With nowadays tooling, these AI agents can take you down in no time if they target you.

Compliance the way is done today is basically outdated, but everyone has to follow these rules to sell software basically.

Post reply on HN