5 ms·

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

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.

lallysingh 8y ago
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.
- matt_the_bass 8y ago
  Curious, why do you say “old programmers would do much worse”? That hasn’t been my experience.
  - fcbrooklyn 8y ago
    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.
    - matt_the_bass 8y ago
      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.
      - fcbrooklyn 8y ago
        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.
    - danmg 8y ago
      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.
      - fcbrooklyn 8y ago
        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)
        icedchai 8y ago
        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.
        danmg 8y ago
        Could have been under-clocked by (div 4) just to torture people into writing efficient code.
        fcbrooklyn 8y ago
        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.
    - lallysingh 8y ago
      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.
fcbrooklyn 8y ago
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".
- matt_the_bass 8y ago
  Thanks. That’s a good example.
- danmg 8y ago
  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 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.

lallysingh 8y ago

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.

matt_the_bass 8y ago
Curious, why do you say “old programmers would do much worse”? That hasn’t been my experience.
- fcbrooklyn 8y ago
  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.
  - matt_the_bass 8y ago
    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.
    - fcbrooklyn 8y ago
      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.
  - danmg 8y ago
    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.
    - fcbrooklyn 8y ago
      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)
      - icedchai 8y ago
        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.
        danmg 8y ago
        Could have been under-clocked by (div 4) just to torture people into writing efficient code.
        fcbrooklyn 8y ago
        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.
  - lallysingh 8y ago
    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.

fcbrooklyn 8y ago

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

matt_the_bass 8y ago
Thanks. That’s a good example.
danmg 8y ago
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 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.