The Morris Worm had a literary inspiration in the form of John Brunner's 1975 "The Shockwave Rider", one of the earliest depictions of computer hacking [0]. A great book that still stands the test of time.
> A great book that still stands the test of time.
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.
This talks a good bit about how some of the default passwords the Morris Worm checked for in 1988 are on the list of commonly used passwords in 2018. Which is kind of sad but understandable and somewhat excusable because, we’ll, humans.
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]
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.
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.
"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?
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.
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.
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.
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.
“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.
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.
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.
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?
But ten years ago, the go-to solution to avoid buffer overruns was still the same as another ten years earlier (languages like java) and it was already depressingly clear that this solution would not spread further into the domain of C/C++ than it already did. Today, the hope lies with Rust and we are yet to discover the eventual limits of its adaption. The trajectory hasn't looked better than today in a very long time.
>What of the Morris Worm’s other entry method, based on weak passwords?
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.
How did an article about works turn into a rant about Google?
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
One fact that's seldom reported is that RTM's father, Robert H. Morris Sr, started working for the NSA in 1986, two years before RTM unleashed the worm. Food for thought maybe?
Thing I love (puckishly, I admit) pointing out: Paul Graham features in Hafner and Markoffs telling of the RTM worm story in _Cyberpunk_ (as I recall, he's a go-between for RTM and the reporters).
Also of note: Cliff Stoll deals with the worm in his excellent _The Cuckoo's Egg_ book, including discussions with Robert Morris Sr (RTM's father), who was chief scientist at the NSA at the time.
Cliff Stoll now sells beautiful handmade Klein bottles out of his Berkeley home (by appointment) and is a lovely guy to visit. These are, for my money, the finest non-orientable manifolds available in the Bay Area today.
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 feel so old. Thirty years? I was working in my office (actual _office with a door_, not a cube) at Prime Computer when people began wandering the halls, asking, "What happened to the Internet?"
Mostly, for me, it meant I couldn't access alt.music.katebush.
It may seem quaint now, but it cost many of us a great deal of time back then and was a huge PITA.
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?)
It fills my heart with nostalgia when I remember how decades ago experts said "It's dangerous to open .exes someone sent you by mail. Images and data files are fine, they don't run and can't infect your computer".
There is always a local angle (H. Caen). Robert Morris Sr was a cryptographer, chief scientist of the NSA, and father of Robert Tappen Morris, Jr. Robert Tappen Morris Jr. was the creator of the Morris Worm. He is a friend of Paul Graham and is a partner in Y-Combinator.
42 comments
[ 3.0 ms ] story [ 92.0 ms ] thread[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.
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....
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.
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...
https://github.com/arialdomartini/morris-worm/blob/master/cr...
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?
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
Just a coincidence.
https://www.kleinbottle.com
I saw him give a talk once; he's an extraordinarily good speaker.
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?
Mostly, for me, it meant I couldn't access alt.music.katebush.
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.