As I keep saying, we should spend less time developing "better, safer" tools and practices and more time making sure the developers that use them know what they're doing. The bugs caused by lack of memory safety are rare (although often more critical) compared to the bugs caused by developers not paying proper attention to what their code does in the first place.

https://theregister.com/2023/01/...

There was a similar rant some time ago where I posted exactly this.

Doesn't matter how "safe" the language claims to be. Clueless people will find ways to break shit and create vulnerabilities.

Therefore, no, rust isn't safer by default, because as long as "unsafe" exists, people will take shortcuts, not caring that unsafe means, well, unsafe.

Reducing the inherent complexity of the tools we use is still an important goal for the industry at large.

@spongessuck Well yes, but actually no. Ultimately the problems we're trying to solve with software are complex, and they're only getting more complex because the simple ones have already been solved. Sure there's some overengineering and unnecessary complexity in the tools that we have, but removing those issues only goes so far. Reducing the complexity any further just means hiding the true complexity behind a nice interface until something goes wrong. That might be fine when you're trying to sell something to the end user who doesn't mind paying for an expert to fix such problems every now and then, but that's definitely not what you want when you're trying to run a business and make profit.

@hitko

Couldn't have said it better.

They aren't rare, they're hard to discover, vigorously checked in PR reviews, and we never learn about those that fall through. Go, check how long the most famous bounds checking errors survived before they were discovered by somebody who actually reported them. The average will be well over two years. You will never know how long they have been used at that point. Just the fact that every std datastructure is bounds checked makes Rust a huge improvement over c++.

@lorentz

Just like using gsl::span over raw arrays...

I'm way too drunk to do this right now but I'll add it to a list, eventually it'll make a nice article. Estimating currently dormant critical vulnerabilities based on the lifetime of past discoveries.

@lorentz

Good thing. Tomorrow I'll get so drunk Sunday probably won't even exist 🤘

@lorentz And what's the practical impact of those bugs? What was the last one that was easy to exploit on a similar scale as, say, log4j? What was the last one where an attacker could simply send a few malformed HTTP requests and crash thousands of servers? Exploiting bugs caused by lack of memory safety usually takes a series of complex steps to get any valuable outcome, and most of the time the attacker already needs some level of access to the system to perform them (at least user clicking a malicious link), whereas bugs caused by simple ignorance on the developer's side are the ones that have been the easiest to exploit on scale and the hardest to prevent by simple "common sense" security measures on the user's side.

@hitko Fair point on log4j, I guess memory safety is just a specialization of abstraction safety; Encoding a data source in a string is isomorphic to encoding it as a function and associated data in an array of bytes, and in both cases the methods of creating and accessing the abstraction need to ensure that the meaning cannot be altered.

Of course, since Java is turing complete, nothing can stop programmers from reproducing C's memory aliasing vulnerabilities on top of it. Still, if your view into memory is an unsafe abstraction, your environment will never consist of purely safe abstractions. If it is safe, the only way to introduce abstraction vulnerabilities is by writing new abstractions that violate their own guarantees.