Hacker News new | ask | show | jobs
by chx 4011 days ago
With all due respect to you, everything would be different. I know even then it would've been a daunting thing to do but perhaps 1998 was the last year when it could've been done: tear it down and rebuild it securely.

I am sure you know this too well but let me remind a few people here who were not even born when some of this happened: The early years were mostly of trust. As an example, I remember running around even in 1994 with a 10BASE2 network tester to find where the network broke. 10BASE2 was a perfect example of a more trustworthy age: many machines shared a single cable and eavesdropping required zero effort. Every machine got all the frames and there was no encryption. Then came Fast Ethernet and with it 100BASE-TX and slowly switches replaced active hubs and this went away. But it often required rewiring buildings which took a long time. I do not have hard data and it's hard to define the start and end points but I would say it took at least five years if not a whole decade to really sunset 10BASE2.

Now of course doing the same on a world level would've been a daunting task. However the number of websites at this point were growing somewhat sedentary at least compared to years prior and later, see the data http://www.internetlivestats.com/total-number-of-websites/ here, compared to the meteoric growth in 1997 (334%) and 2000 (438%) the years 1998 (116%) and 1999 (32%) were slow and peaceful.

3 comments

I understand that's what people think, but what I'm saying is that in 1998, we wouldn't have known how to rebuild everything securely. We'd have ended up with slightly better C standard libaries, S-BGP, IPSEC, and DNSSEC.

Here, let me sum it up this way: I think it's possible that the L0pht testimony predates SQL injection.

Buffer overflows were certainly recognised considerably earlier than that. I remember a colleague pointing out buffer overflows in the first STL string implementations. It's not hard to go from that to SQL injection, or any other similar technique.

Certainly, my (possibly rose-coloured) memories of the time includes a lot of, "OMG. How stupid can people be? Surely they know better than that!"

I guess what I'm saying is that some people definitely knew what to do about this and were trying to do it. Most people were ignoring it and saying things like, "Oh, you're just being paranoid. Why would anyone try to do something like that?" It's a bit pointless to say, "What would have happened if people had listened" because the point was that people didn't listen. That was the whole problem.

The first modern overflow exploit was Thomas Lopatic's 1995 HPUX httpd exploit. When he wrote it up, he claimed it followed the blueprint of the "microscope and tweezers" paper Spafford wrote about the Morris worm. The Morris Worm, of course, was from 1988. In the years between 1988 and 1995 there were, so far as anyone knows, a total of zero code-exec buffer overflow exploits.

I was in the room with Peiter, at a DC Summercon, as he tried to work out the exploit for Sendmail 8.6.12 that 8lgm had teased. He definitely didn't have it before 8lgm, and 8lgm didn't have it before Lopatic. Even the virus guys didn't have it.

It's weird to think that nobody put two and two together in, say, 1991 --- there certainly was motivation (that's the timing of the Sun-Devil Raids!) and so much vulnerable software.

But then, in the late 1990s, people honestly thought they could mitigate overflows by moving buffers from the stack to the heap. Reliable heap exploits were a big deal as late as 2003, when Matt Conover spoke to a packed CanSec room about the Windows Heap, in excruciating detail for over an hour. That's close to a decade between Lopatic and mainstream heap exploitation on modern heaps.

>shrug<

It is possible that I am misremembering. I remember him submitting a bug and being ignored as a crank, though ;-). It may have been some other kind of memory corruption.

It's hard to believe that it's only been since the late 90's that buffer overruns exploits have been around. I will have to believe you as you have considerably more knowledge on the subject than me.

I'm very much wondering now about the times I used to boot trace games to crack them and if I ever used such a technique. It seems so obvious now that I may be assuming that I must have, but it's so long ago that I really can't remember. Certainly getting the loader to move your code around rather than theirs was a normal trick.

I'd say buffer overflows "went mainstream" roughly after November 1996 when Phrack 49 with "Smashing the Stack for Fun and Profit" was released. At least I'd guess that's the most influencing article on the topic.
I thought by then there was at least some awareness - old memories of people evangelizing prepared statements with placeholders – but this was the oldest reference I found, from December 1998:

http://phrack.org/issues/54/8.html

Hrm you are right it certainly predates XSS http://www.thesecuritypractice.com/the_security_practice/201...
> better C standard libaries

What's the story with C standard libraries and security? How could they be better, as you see it?

You see, this is a much older discussion than most folks think. Back in the 70s, there was a lot of talk then about how badly software was built. "If buildings were built the way software is built, the first strong wind would destroy civilization". Remedies were proposed, dogmas (er, sorry, methodologies) developed, proselytized, replaced. Languages came and went. Howling winds came (see the "voodoo gods" in Count Zero) when we connected this all to the internet. Y2K came and showed some of the underbelly.

So, tear it down and rebuild it securely is actually many years to late 1998.

There are a few that know how to build software that isn't swiss cheese. Just picking two that I know of, nobody reads the whole volume set (as noted in Coders at Work), and for the other one, nobody wants to use it because it isn't under active development. The idea, even today, that a chunk of important internet software can actually be finished seems to be met with cognitive dissonance.

And there are organizations that know how to build very good software. But in todays fast moving businesses, who wants to be in a CMM 5 organization? Doesn't sound like much fun to me, and probably not to you either.

My estimate of the last year that all of this could have been fixed was at least 30 years earlier than your estimate. Or sooner. I worked in an organization whose core software, running today, was first written about 50 years ago.

"Tear it down" never happens for systems that are basically working, even if they have serious flaws.
It definitely happened to 10base2!