My favorite vulnerability is not often mentioned: The sendmail config file used to have a completely byzantine syntax. Consequently, there was a default wizard password that would grant total strangers access, with the understanding that these would be whitehat wizards breaking in to fix your braindamaged mail configuration.

The reason for the "whitehat" assumption was really that no one had seen any other color of hat (because why would you break in and do something malicious wtf haven't you got anything better to do?)

Simpler times.

Simpler times indeed.

But it overlooks what I think is actually a way sadder and bigger issue: The Morris Worm utilized a buffer overflow in fingerd as one of its propagation mechanisms.

Here we are 30 years later and still dealing with code execution vulnerabilities because of various memory mismanagement issues. [face palm]

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.

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....

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.

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.

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.

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.

"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...

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.

https://github.com/arialdomartini/morris-worm/blob/master/cr...

[0] https://en.wikipedia.org/wiki/The_Shockwave_Rider

Agree. I think one of the reasons is that Brunner doesn't actually precisely describe the technology except in terms like 'the home phone service was tied into the net'. This makes it very easy to superimpose our modern perceptions onto a book that is now 45 years old. It's almost less jarring than the mid-80s cyberpunk classics such as Neuromancer with its no-mobile-phones and line-printers-in-space-stations.

https://www.kleinbottle.com

I saw him give a talk once; he's an extraordinarily good speaker.

Mostly, for me, it meant I couldn't access alt.music.katebush.

One should include those few companies that are serious about zero-day vulnerabilities and IT security in general. For example, they should be active with bug bounties.

The other one should include stock of rest of market, with proportion of sectors close to first.

I wonder, which would do better?

Oh, but we all know that this is totally fixed by 5-factor authentication. You just type in your password, click on an emailed link, type a pin from your mandatory cellphone app, undergo an ECG and then send in a urine sample. And then you're logged in. It's super easy, and if you're not using it, it's your own damn fault. Even when the website you're using doesn't support it. Just get over it and stop using websites not owned by Google already.

2 factor authentication is probably the best way to mitigate against automated attacks like this worm. Its unrealistic for root os access, but if more people required an email or text to verify a login, there would be a lot less hacks in the world

There were small pieces of RTM's original code in the famed "Cornell Report", which showed that at least this code is not RTM's original code.

Are other decompilations floating around? Did RTM's original code ever get leaked?

Just a coincidence.