In some mail from Anton J Aylward, sie said:
[...]
> For example, the buffer overflow problems we've seen between the
> Morris work and other things recently were becuase the programmer
> never imagined the application would have to deal with perverse SOBs
> shoving extra stuff down. Then when we saw how the Morris worm
> worked, we were collectively guilty of not imagining it was a technique
> which could be used elsewhere.
A digression...
It doesn't take imagination to look at a function or system call, the
parameters it takes, and extremes of input. This is part of formal
design/testing for software; or so I thought.
gets() is not a case of imagining peverse input, but simply what is the
range of legal input values and can my buffer handle them all ? Same
for most buffer related code. Peverse input only matters when you start
parsing it, sometimes producing unexpected output.
If you read in input using fgets(), is there room for a NULL on the end ?
Do you put one there, anyway ? Do you do this before searching for any
text (such as newline) in the buffer ? IMHO, very simple things.
At NS'95, on the Saturday morning there was a tute. "Security and the
World Wide Web", taken by John Stewart of Cisco Systems, which had a
largish section on programming using shells, perl and C, in a secure
fashion. There wasn't anything astounding mentioned, nothing requiring
imagination of weird input, except maybe for shells/perl and the presence
of ``. Most of it was common sense when doing things like sprintf, strcpy,
gets, etc. If you'd like a copy of the notes, you should be able to email
the Network Security Institute (who ran it), at:
nsi @
fedunix .
org
The moral here is not necessrily be imaginative; just don't make assumptions
that everything will be correct in the real world.
darren
Follow-Ups:
References:
|
|
