--On Wed, 30 Aug 95, Padgett Peterson responded to:
...programming to begin with.. Almost every hole that has come out in
the last 2 or 3 years is because people that wrote programs assume
that all data is good..
--with:
The problem is that if you assume that all of the data is good, you can
write
the program in 1/3 the time. Looong time ago I found that the exception
cases
are what take the bulk of your time (back then everything was from the
command
line. I used to write things such that is all the necessary data was there
and parsed properly, it assumed the user knew what they were doing. If not,
help menus and suggestions ("myzlplk is not a proper command, did you mean
to invoke the menu ? Press <cr> to bring up menu or enter any other valid
command.") were displayed - was a lot like KERMIT is today except
friendlier.
Back at the time when "user-friendly" was a buzzword, mine was
"user-stupid".
Buffers only overflow if you let them, is really one of the easier things
to keep track of and there are many answers that just take care in
programming.
--My comments:
Having been a previous 'core reader' and a person whose job involved finding
and fixing system crashes, I agree with Padgett. I've seen lots of instances
where programmers test programs by using only 'correct data' and only in the
'correct sequences'. In many cases, programs don't report error conditions.
It is a pain to always check for "NULL" after attempting to allocate memory
and to check for buffer overflows. Makes code downright hard to read since
the flow of the program is cluttered with error checks. Yet, I depend on all
this 'extra' code to make sure that people can't crash my firewall by
overflowing memory with long lines, enormous mail recipient lists, busted
network packets, and such. We all depend on our vendors doing reliable error
handling and "failing safely".
The problem I see today are things like the WORD 6 executable, applets, and
other "feature" code which can transform a correctly formatted and valid
transaction (mail, for example) into a security hole by performing actions
which shouldn't possible without users knowing about it. (This brings up the
next problem...) Imagine what would happen if some programmer added a shell
escape command into the login processor (after all, they reason, all the
other UNIX commands have shell escapes). All this new
"feature/functionality" code doesn't work in a vacuum and has the capability
to void much of the work we do with firewalls by providing an uncheckable
path for undesirable code. If history repeats itself, the industry will
respond by making changes to the operating system (ex: limit capabilities by
changing the "root" directory). This option, though, isn't possible on PCs
and .......
|
|
