[lmm]

> 2 of the 3 biggest security vulnerabilities I’ve had to deal with in my career were completely unrelated and wouldn’t have been prevented had software been written in Rust instead.

The last study I saw was that 52% of security vulnerabilities were still basic memory safety vulnerabilities. Memory safety isn't the only thing, but it's still the biggest thing.

> (if your depending on ‘cat’ or ‘awk’ to be bug free for your application to be hardened then you’re already doing it wrong)

People run cat or awk on log files (where an attacker could easily craft particular data patterns) all the time. Maybe they shouldn't, but they do.

[laumars]

> The last study I saw was that 52% of security vulnerabilities were still basic memory safety vulnerabilities. Memory safety isn't the only thing, but it's still the biggest thing.

My point wasn’t that memory safety isn’t a big issue. It’s that it’s not the only cause of vulnerabilities. Assuming your 52% figure is accurate (and I’m happy to take your word on that) that still means that roughly half of all vulnerabilities are not memory safety. Which means your figure actually just reinforces my point.

> People run cat or awk on log files (where an attacker could easily craft particular data patterns) all the time. Maybe they shouldn't, but they do.

I think there’s enough obscurity there hidden from the attacker that such usage should be safe from all but the most determined of attacker. And even then, they’d likely need some other attack to probe for usage about what systems are listening to what logs and using which POSIX utils that you could argue the attacker already has the access they need without going to the pain of crafting an overflow bug in a log file.

Im not saying those bugs don’t exist nor shouldn’t be addressed, I’m just being pragmatic about their exploitability.

The bigger issue is CI/CD pipelines. Often they’re define in the same mono-repo as the source itself and they’ll have execution rights automatically because that’s literally their function as a build and test pipeline. But because said pipelines are already visible and already executable, you need to have greater controls around that pipeline to prevent abuse otherwise it’s already game over even without an overflow bug.

[lmm]

> Assuming your 52% figure is accurate (and I’m happy to take your word on that) that still means that roughly half of all vulnerabilities are not memory safety.

Sure, but that half is every other category of bug put together. I guess if your model is that every other class of bug will be significantly increased by a rewrite then maybe that logic makes sense, but that seems unlikely to me.

[laumars]

You’re making strawman arguments. None of the points you’re proving are anything I’ve disagreed with.

Try reading the thread again

[lmm]

You said "Half those applications are going to have other classes of new bugs simply because it’s new code and they’ve had less people audit the code", and when I pointed out that such bugs would most likely not be security bugs you responded by saying that many security bugs aren't memory safety bugs. You may not have intended to say what you said, but what I'm disagreeing with is what you said, not a strawman, and even if you were right your condescension would still be unwarranted.

[laumars]

Firstly, I’ve not been condensing.

And yes, I did say that at the start of the conversation. Sorry I’d forgotten about that part because this conversation had taken a tangent on discussing other specifics in security.

I do stand by my comments, a rewrite does introduce new bugs and not all security bugs are buffer overflows. Rust doesn’t protect you against bugs like Shellshock. They protect against bugs like Heartbleed. But people frequently forget about the former when focusing on the latter. So absolutely we need to be considered when replacing battle tested software with an entirely new code. It’s not an unfair meme when people state this. If it were an easy and risk free upgrade then we’d have already done so in one of the other safer languages that predate Rust. A lot of what’s changed between then and now isn’t that languages have gotten better, it’s simply that Rust is trendier than any of the safer languages before them. And that’s a pretty awful reason to reason to rush a complete rewrite of the entire stack.

Source: I’m an old fart who’s been writing safe code in safe languages for 30+ years.

[lmm]

> Firstly, I’ve not been condensing.

"Try reading the thread again" is extremely condescending.

> Rust doesn’t protect you against bugs like Shellshock. They protect against bugs like Heartbleed. But people frequently forget about the former when focusing on the latter. So absolutely we need to be considered when replacing battle tested software with an entirely new code. It’s not an unfair meme when people state this.

Like I said, over half of security bugs are the kind of bug that Rust protects you against, whereas the other half (apparently more like a quarter, per side thread) is every other category of bug put together. So unless your model is that every other category of bug will be significantly increased by a rewrite, the rewrite wins out on net.

> If it were an easy and risk free upgrade then we’d have already done so in one of the other safer languages that predate Rust. A lot of what’s changed between then and now isn’t that languages have gotten better, it’s simply that Rust is trendier than any of the safer languages before them.

Per another side thread, I do agree that the reason people are rewriting in Rust now when they weren't rewriting in OCaml 10 years ago is mostly trendiness. But I disagree about which of those two decisions is the mistake.

[steveklabnik]

(The actual number is more than that, it’s roughly 70%. This number was reported by at least Microsoft and Chrome, among others. That roughly the same number has popped up across many large companies helps us gain confidence that it’s roughly correct, though obviously it’s not a law.)

[laumars]

The domain matters a lot here though. If you’re talking about bugs in Chrome then yeah, you’d expect it to be weighted towards buffer overflows. But if you’re taking about bugs in a build script someone has written, then I’d wager human error (given commands and have shells have a pretty esoteric syntax) are more of a problem — and certainly easier to exploit - than a buffer overflow in awk.

Don’t get me wrong, I’m all for writing stuff in safer languages (I personally haven’t touched C in years for that reason). But simply throwing Rust at the problem without assessing the risks is just as careless. In the case of most POSIX base utils, the risk isn’t buffer overflows, it’s people exposing internal tools to untrusted external users.

Take shellshock for example, that’s a prime example for just how careless people can be. And while there was patches to fix that vulnerability in Bash, people shouldn’t have been writing software that passed untrusted data to Bash in the first bloody place.

My point is: Security is a multi-layered problem. So by all means let’s pivot towards newer, safer, languages of it can remove an entire class of bugs. But let’s not pretend that rewriting the entire of POSIX in Rust is either practical nor the end of the discussion. And if we acknowledge it’s not, then we must also acknowledge there’s already things we can do to harden against our C++ utils today while those C++ utils are still a necessity.

This is why the Rust argument fucks me off. People expect too much from it and use it as an argument whenever other countermeasures should have been in place irrespective of the vulnerability that was inevitably used.