News for hackers. Stuff that matters.
Re:OpenBSD system-call-origin verification by vlovich123 on Tuesday December 24, 2019 @03:14AM (#21870670)
So let's assume the argument you're making is valid. ASLR is security theater because it protects against dumb attackers and fixing buffer overflows is the real solution.

Let's ignore that only recently have languages become available that make it possible to do so for high-performance code. That's a straightforward problem to solve - we know how to rewrite code in other languages, we can build tools to help us do it effectively, etc.

Let's also ignore that the recency of the languages mean that few people know how to code that effectively. We can train armies of engineers.

Let's ignore that training engineers takes significant amounts of time & shifting massive industries is difficult. That will be solved over time.

Lets ignore that Rust is more difficult to write than C/C++ - after all we're just converting existing code so that could be easier & the more time spent during writing is paid off by less time debugging at runtime.

Let's also ignore that A LOT of money has been poured into existing software and a non-trivial amount would have to be donated/volunteered to migrate to languages where it's impossible. We have OSS volunteers and enthusiasts and corporate interests are aligned to sponsor conversions.

Let's ignore that it takes time to integrate new languages into large corporations with existing build systems, infrastructure, tooling, etc. They'll solve that - again, interests are aligned here.

Let's ignore ALL of those issues. XSS, Rowhammer, Meltdown, Specter, downgrade attacks, man-in-the-middle, spear phishing, bugs in cryptographic algorithm design, side-channel attacks, etc are all still security attacks that have very real, and perhaps sometimes more serious, consequences than buffer overflows and waving a magic wand and fixing all buffer overflows wouldn't really adjust the security landscape we deal with today (maybe exploits would get more expensive - maybe, but ASLR et all do that too).

Following the same logic you laid out, this focus on buffer overflows at all is just security theater: ASLR is to buffer overflows what buffer overflows is to all security bugs overall. Back in reality ASLR, syscall origin verification, etc are all tools to try to mitigate the impact of all the things we ignored above & we know they have an impact because exploits keep getting more expensive, the low-hanging fruit bugs always get patched quickly, etc.

So sure, once the world has switched to Rust and we can turn off all these other protections that make buffer overflows more difficult. Oh, except we can't because now we remember that Rust has "unsafe" & that's used A LOT for various reasons. So now you need those protections anyway in case there's a bug in the unsafe code. And I 100% promise you there will be exploits there or in the Rust compiler. We can have confidence this will be the case because it's already happened: https://medium.com/@shnatsel/how-rusts-standard-library-was-..., https://blog.rust-lang.org/2019/11/01/nll-hard-errors.html). So your claim that we know how to fix buffer overflows is just inane even on its face. Hell, this isn't even a Rust-specific thing. I would be very skeptical if you could find a single semi-popular language without a buffer overflow bug of some kind somewhere, even in managed languages. The Java VM is full of them. Go has them. etc.

TLDR: You may want to reexamine your arrogance. Security is an extremely hard topic that will never get solved. Are there shitty programmers? Sure. Are security problems exclusively written by them? No. Security issues are an emergent property of complex systems. Some are easy to solve once and for all once the root cause is known. Others are MUCH harder.

There are no comments on this comment yet.