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

211–220 of 270 posts

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

#211

Post by tialaramex »

tptacek wrote: post #203
kasey_junk wrote: post #202

Earlier quoted context omitted.

PCI doesn’t mention cve by name but does require vulnerability accounting and requires action if they are found, the action required driven by severity. I could see a (poor) control being written around keeping counts down.

Right, you can write a bad SOC2 control that cares about CVE counts too!

I've met good auditors. I mean, I've met terrible auditors too, but the good ones stick in my mind more because they ask insightful questions about my software or sometimes software in general. It's a problem that this is often seen as a box ticking exercise, done right it can be a really great opportunity to improve but so often instead the priority is to get the paperwork done and too bad if you achieved nothing by it.

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

#212

Post by uecker »

hurril wrote: post #186
blub wrote: post #163

Earlier quoted context omitted.

These Rust discussions typically contain grains of truth wrapped into exaggerations while downplaying or ignoring the two big issues of Rust, which are complexity and out of control dependency trees. For the first issue of complexity, the reply is along the lines of show me the code and then either nitpicking that to pieces or explaining in several paragraphs how the behavior is perfectly reasonable and in fact quite…

I would argue that what you call complexity here is better referred to as explicit or visible complexity, as compared to hidden or implicit commplexity. The complexity as such comes with the domain and its application; but with Rust you can see it and you are forced to deal. With C++ you can get away with pretending that it is in fact not there. This is honestly not intended to pick on C++ as a Rust fanboy, however.…

There are certainly good parts in Rust that force you deal with inherent issues explicitly. I do not think this justifies a language with the complexity of Rust, but I would agree it is preferable to C++ in this regard.

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

#213

Post by saghm »

pjmlp wrote: post #210
saghm wrote: post #156

Earlier quoted context omitted.

> 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'll believe this when he can actually point to non-trivial, real-world C++ codebases that have managed to avoid having memory unsafety following these techniques. "It's technically possible for this issue to be avoided" is a lot easier to say than it is to actually make work…

The recipe is tame C and C++ as much as possible, on the language level, toolchains and hardware memory tagging, following by writing new code in something else like Swift. See Meet with Apple, security event. Naturally they aren't going to throw away LLVM, DriverKit or Metal Shading Language, so there is a compromise there.

My point is that there are plenty of smart people touting various recipes for safe C++, but somehow vanishingly few instances of actually safe C++ codebases. It's hard not to feel like the claims that C++ can be made safe are mostly being made from an abstract theoretical viewpoint and not a pragmatic one, because even the companies with the most resources or the smartest people don't seem to be able to pull it off.

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

#214

Post by tialaramex »

mk89 wrote: post #150
mk89 wrote: post #112

Earlier quoted context omitted.

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.

So lets take some recent examples from the sprawling systems my team looks after

1. There's a "critical" severity security issue because we have an obsolete version of some Perl library on a machine that's exposed to outsiders (ie has a public HTTPS website)

1a. The perl library isn't used by any of the software running on that machine, it's presumably either left over from software we no longer use or it was installed to run somebody's one-shot Perl script, possibly years ago, maybe even for a prior incarnation of that system, with the present one installing that library because it's just easier than figuring out which libraries are still needed...

1b Severity CRITICAL. Actual threat: ZERO

2. .NET 8 is obsolete, machines with the .NET 8 CLR are flagged as insecure.

2a. .NET 10 isn't obsolete, that's still supported, in many cases the exact same code, re-compiled with a 10.x version not 8.x was shipped by Microsoft. Is that true for all the cases we care about? Nobody knows, nobody is even interested in working out. Flagged instances will be turned off if they're not fixed so "just" fix it. Busy work.

2b. Severity HIGH. Actual threat: Unknown, possibly negligible?

As with Mythos these "AI agents" which can "take you down in no time" can't do the impossible, this isn't a Hollywood movie, mumbling about AI and critical severity CVE doesn't turn that Perl library nobody was using into an actual threat.

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

#215

Post by saghm »

pjmlp wrote: post #201
saghm wrote: post #155

Earlier quoted context omitted.

Honestly this just makes it sound like C++ people either didn't really care about it in practice or just were weirdly insistent that they get to decide how to integrate the language into an existing project. At best, it's just another instance of the claims that C++ could totally do everything Rust does (but somehow still never seems to in real life), and at worst it just kind of reflects poorly on the social skills…

Too busy contributing to Symbian, Windows, macOS, BeOS...

Sure, not caring about contributing to Linux in practice is valid, but at that point it would make more sense just not to argue about the aptness of C++ for integrating into Linux at all then if no one ever legitimately tried. My point is that the parent comment is trying to have it both ways by arguing that C++ totally could be integrated into the Linux kernel as a dismissal of the real-world case of Rust being integrated but then ignoring the actual real-world case of C++ not getting integrated into the kernel.

At a higher level, I've noticed a long-term trend where dismissals of Rust from C++ proponents have continued to grow increasingly abstract; the line of reasoning basically seems to be that how Rust is used in practice can be ignored as long as there's a sufficient theoretical argument for C++ being able to do the same thing. This is a remarkable retreat from the previous objections to Rust being impractical compared to C++ which I'd argue is itself evidence of the ground that Rust has gained in the past several years. It seems to have happened without the C++ community noticing though, which at least in part seems to come from some cognitive dissonance; in your two replies to my comments in this thread, you demonstrated this yourself by arguing on pragmatic grounds about how C++ is used in practice in this comment but then rejecting criticism of C++ in your other comment by asserting that a "recipe" for memory safety is enough to dismiss concerns about how pretty much no real-world project actually achieves this.

My (obviously biased) perception is that the shortcomings of Rust tend to be pretty widely agreed upon by the experts in the community and mostly dismissed by people who honestly aren't nearly as experienced in the language, whereas with C++ the most expert members of the community seem prone to handwaving away concerns that deserve a lot more attention.

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

#216

Post by tptacek »

tialaramex wrote: post #211
tptacek wrote: post #203

Earlier quoted context omitted.

Right, you can write a bad SOC2 control that cares about CVE counts too!

I've met good auditors. I mean, I've met terrible auditors too, but the good ones stick in my mind more because they ask insightful questions about my software or sometimes software in general. It's a problem that this is often seen as a box ticking exercise, done right it can be a really great opportunity to improve but so often instead the priority is to get the paperwork done and too bad if you achieved nothing by…

If we're talking about actual auditors, not tech consultants who call themselves auditors but people actually trained as auditors, I'd take it as a bad sign if they asked a bunch of specific unbidden questions about software details. That's not the job.

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

#217

Post by [deleted] »

uecker wrote: post #209
Ygg2 wrote: post #170

Earlier quoted context omitted.

> And as as the Cloudflare incident showed, a Rust unwrap can have equally bad consequences. Arguably less bad than silently corrupting your data and forcing you to do CAPTCHA everywhere. Which is what the parallel Perl(?) component was doing at the time. Rust solution gave a clear signal something was wrong, the other solution was slowly annoying everyone and pushing them away.

A major global internet outage can certainly considered a "clear signal". Still not sure this was a good thing though.

[deleted]

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

#218

Post by uecker »

saghm wrote: post #145
thayne wrote: post #136

Earlier quoted context omitted.

> 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 prog…

Considering the amount of C programs that exist, the "we see severe bugs in C code seemingly every week" is on the same level of propaganda as we see "crime in the news every week" when the real societal problems are entirely different.

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

#219

Post by Ygg2 »

uecker wrote: post #209
Ygg2 wrote: post #170

Earlier quoted context omitted.

> And as as the Cloudflare incident showed, a Rust unwrap can have equally bad consequences. Arguably less bad than silently corrupting your data and forcing you to do CAPTCHA everywhere. Which is what the parallel Perl(?) component was doing at the time. Rust solution gave a clear signal something was wrong, the other solution was slowly annoying everyone and pushing them away.

A major global internet outage can certainly considered a "clear signal". Still not sure this was a good thing though.

It's not an ideal thing for sure, but between loud bang and silent corruption, I'd probably take loud bang. I.e. I'll take a panic rather than the method return 43 when you pop the null member from the stack.

And the Rust wasn't the root cause but corrupt configs were being erroneusly duplicated.

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

#220

Post by asveikau »

uecker wrote: post #139
asveikau wrote: post #123

Earlier quoted context omitted.

An assert is not guaranteed to terminate the process. In C, the most common implementation choice is to completely omit the check if you're not building in debug mode.

You need to turn it off by defining NDEBUG. While sometimes it is not for release builds, I am not sure this is common.

Visual Studio defaults to defining NDEBUG in release mode, and I think that default was pretty influential
Post reply on HN