[killyp]

Buffer overflows will be an issue as long as code is written in languages that allow memory mismanagement. C, C++ and even Fortran are still here and aren't going away any time soon so this isn't going to change anytime in the near future.

[billyhoffman]

I guess that's what I'm sad about.

Manual memory management feels like how early automobiles allowed you to adjust the fuel/air mixture by turning a knob: Why are you making me deal with this?

There are documents from the US Airforce's computer security group in the mid 1970s talking about buffer overflows. How years and many units of significant digits of precision do we need on the concept that human are fucking terrible at managing their own memory.

Yes [insert argument about garbage collection stalls] and yes [insert argument about guaranteed response times], but for the vast majority of programming projects those simply don't apply.

The fact that is 2019 and we are still dealing with this is so depressing.

[ashurov]

"There are documents from the US Airforce's computer security group in the mid 1970s talking about buffer overflows.": could you point me to this/provide more information?

[schoen]

Presumably this is about Karger and Schell (1974). A 2002 reprint with nicer formatting is at

https://www.acsac.org/2002/papers/classic-multics-orig.pdf

It's sometimes said that they discovered or anticipated a lot of things that would preoccupy us over the next decades. I was personally familiar with them because David Wheeler mentioned that they anticipated the "trusting trust" issue with a compromised compiler.

Some of their terminology is different from current terminology, but there is, for example, a discussion of tampering with the stack in order to alter variables or control flow. I'm not sure whether the buffer overflow mechanism is discussed because the part that I think I understand is a different means of stack manipulation, specific to this environment.

An obituary for Paul Karger:

https://www.ieee-security.org/Cipher/Newsbriefs/2010/karger....

[CoolGuySteve]

The reason these languages are still popular is because they're still the fastest and consume less memory.

A better question is why doesn't x86_64 have hardware bounds checking by now? We can already fault at the page boundary, it seems like a minor improvement to have an instruction for malloc/sbrk to create new dynamically sized pages that fault the same way.

Doing so would also be backwards compatible with all the existing software that relies on malloc.

[Someone]

“Huge/Large/Super pages” (https://wiki.debian.org/Hugepages) exist because the typical 4kB pages have too much overhead in programs that allocate lots of memory.

So, sizing pages down to malloc-sized blocks will impact performance, even ignoring the fact that, to have true bounds checking, pointers will have to carry size information, making them larger (64-bit pointers have quite a few unused bits on typical systems, so it may be possible to hide that somewhat.

Also, if you truly want to do bounds-checking, you will have to create a ‘page’ for every element of every array (either up front or on demand), and, if such elements have structure, for each part of the structure.

[CoolGuySteve]

Huge pages mainly exist to alleviate TLB pressure and page fault latency. But that performance penalty is tiny compared to the alternative of in-program bounds checking that we currently use.

Similarly, pointers don't necessarily need to be changed and your array problem isn't valid. Cachelines could be marked with canaries that fault on read/write, similar to how the NX bit currently works.

The NX bit is actually a good example of a hardware security-performance trade off that nearly everyone agrees on. Now 20 years later, we can afford to mark several more bits at some cache offset for a hardware bounds field.

[brobdingnagians]

Programming in a language other than C++ sometimes feels like putting training wheels on a Ducati and driving 30mph down the freeway. And if you know what you are doing in modern C++, the memory is much easier to deal with. You can do anything and more modern iterations of the language add some nice updates to the syntax sugar. It is rather dense to get your head around it, but once you do it is like writing poetry. I like the idea of just making the hardware safer, is there any downside to that?

[bboreham]

This is broadly how Intel memory segments were supposed to work.

The 8086 did not check bounds, so nobody bothered using them, and when the 80286 came out that could check, everybody disabled that feature and used it as a faster 8086.

Probably too many key programs played too many tricks assuming a flat memory model that this was never going to fly.

[pjmlp]

Just saw this one today.

"Buffer overflow flaw in British Airways in-flight entertainment systems will affect other airlines, but why try it in the air?"

https://www.theregister.co.uk/2019/03/08/thales_topseries_vu...

[sandworm101]

The root issue isn't code but the availability of ram. So long as it is a precious shared resource, overflows are a threat. In the near future the separation between ram and storage may become moot. We could then erect much stronger walls between processes, even separating them physically, so that such cross-talk is much less likely.

[armitron]

Can you elaborate? Putting aside rowhammer-like vulnerabilities [that don't fall under "overflows" anyway], how is shared physical memory under a modern protected virtual memory scheme leading to overflows? Additionally, the word "buffer overflow" usually refers to overflows that take place in the same process.

The process crosstalk (information disclosure, heap grooming, heap manipulation) that takes place to trigger the overflow, wouldn't be affected in the least by physical separation. In many cases (exploitation over the network), you have exactly that.