Bell Labs or Microsoft security?

Marshall Eubanks tme at multicasttech.com
Wed Jan 29 13:50:56 UTC 2003


A world before buffer overflow exploits ?

The first (Fortran) programming course I ever took at MIT on the first 
day of lab they said

1.) If you set an array  index to a sufficiently  large negative number 
you would overwrite
the operating system and crash the system (requiring a reboot from 
punched paper tape).

and

2.) If you did that, they would be so pissed off at you, you would 
summarily fail the course.

This was back when the Fortran complier was included in each run as part 
of the card deck.

I also remember overflow type hacks on the MIT Multics system, which was 
constantly being hacked.

So, I agree with Sean, what were they thinking ?


On Wednesday, January 29, 2003, at 08:18  AM, Richard A Steenbergen 
wrote:

>
> On Wed, Jan 29, 2003 at 03:32:41AM -0500, Sean Donelan wrote:
>>
>> FORTRAN/COBOL array bounds checking.  Bell Labs answer: C. Who wants
>> the computer to check array lengths or pointers.  Programmers know what
>> they are doing, and don't need to be "constrained" by the programming
>> language. Everyone knows programmers are better at arithmatic than
>> computers.  A programmer would never make an off-by-one error. The
>> standard C run-time library.  gets(char *buffer), strcpy(char *dest, 
>> char
>> *src), what were they thinking?
>
> Possibly that bounds checking is an incredible cpu suck, there are a 
> great
> many powerful things you can do in C based on the fact that there is no
> bounds checking (pointers ARE your friend god damnit :P), and in a world
> before buffer overflow exploits it probably didn't matter if Joe Idiot's
> program crashed because he goofed? (hindsight is 20/20)
>
> --
> Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-
> gerbil.net/ras
> GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 
> 2CBC)
>
                                  Regards
                                  Marshall Eubanks





More information about the NANOG mailing list