Hacker News Reader

Comment by matt_the_bass | Hacker News Reader

What does “pre-internet” have to do with “buffer overflows, double frees, dangling pointers”?

I have no evidence, but I wouldn’t be surprised if code from them had less of these since there were far fewer code jockies that just hacked together code they don’t quite understand from google search results. I think most programmers then were much more classically trained.

View on HN

I was there. We had plenty of those kind of problems in those days. I also had the classical training of which you speak, but the industry was far ahead of academia in terms of actually dealing with that kind of thing. The reason pre-internet is relevant is that the penalty for a buffer overflow in 1995 might be a crashed app, or maybe a corrupted file. It was only later that the penalty became "getting pwned by some sophisticated bit of malware and needing to send monero to someone to get your compter back".

Thanks. That’s a good example.

Buffer overflows to gain remote access to a computer were fairly well known in 1995. "Smashing The Stack for Fun and Profit" (http://phrack.org/issues/49/14.html) came out the following year.

Most people weren't really writing network facing code though, so most buffer overflows were as you described. They just resulted in seemingly random crashes.

No, old programmers would do much worse. And the threat model for those systems didn't take in the web as an attack surface. The bugs described would only help with local privilege escalation before. Now they can be used to get access to the networked application.

E.g. the browser uses a vulnerable library call with input from a web page, and that library call alters the return stack according to the input. The browser is now compromised.

Curious, why do you say “old programmers would do much worse”? That hasn’t been my experience.

I don't think they mean "old" programmers exactly... more like "programmers back in the day". We just didn't have the quality of tools back then. Also, our machines were orders of magnitude less powerful, which meant we generally had to work with a lot less in the way of things like library support, frameworks, etc. I used to have an OS/2 box as my build machine. I think that box had 32k of RAM, and 4.7Mhz processor.

Yes, not nearly the quality of tools. When I was programming back then I programmed much closer to the cpu (less abstraction through libraries and less automated tools). This made me look much closer at the issues listed above. I also ready full books on the programming language and command sets. Unlike now, if I use a new library/language, I just scan the online docs to get the gist of what I need to do.

So I guess I had the opposite experience.

Yeah, I did all those things as well. They were essential. And yet I would say that at least 50% of the bugs we ran into were either buffer overflows, stack overflows, using freed pointers, not freeing pointers, or incorrect pointer indirection. At least we didn't have to worry about race conditions.

Your boss must have really hated you to have you run OS/2 on 32k of RAM at 4.7MHz. I didn't even know that was possible.

Oops! 32 Meg, not K. 4.7 is correct I think though.

That machine was probably worth about 3-4 grand at the time (1992)

4.7 mhz is probably not correct. That was the speed of the original 8088/8086 machines (IBM PC 5150 class, etc.)

You would need at least a 386 to support 32 megs of RAM. Those were at least 16 mhz.

Could have been under-clocked by (div 4) just to torture people into writing efficient code.

Heh... see, it was the distant past, fading from my memory. You're absolutely right. The machine in question was an early pentium box as I recall, and the fastest machine I'd ever used at the time.

Yes, precisely. I count myself as one of them. SO and other things online provide a minimum quality level for many solutions, and we didn't have that a few years ago. So you did what you could with the meager time and resources available.

Reply on news.ycombinator.com