RE: Origins of Security Problems

["Michael S Hines" <mshines () purdue edu>]

I think you have made a valid presentation, but come to the wrong
conclusion.

The problem started with bad specifications.  No thought was given to how
the ports(UNIX)/services(Win) could be abused - and how to defend from
abusive attacks.  The goal/success measure was to 'make it work' - without
doing the complete system design to specify handling of unusual conditions
in programs (null input, foreign inputs, incomplete inputs, behavior at peak
demands - that is to day - the 'boundary conditions').  I used to call this
'defensive programming'.

Bad specifications along with incomplete testing produced the network
services we have today.  

Firewalls and Intrusion Detection systems are merely patches to prevent 'bad
things' from reaching incomplete systems software.  If we had properly
behaving ports/services - there would be no need for this extra level of
protection.  

At least that's my opinion.

Mike Hines
-----------------------------------
Michael S Hines
[EMAIL PROTECTED] 


-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Mark Rockman
Sent: Tuesday, June 15, 2004 12:56 PM
To: [EMAIL PROTECTED]
Subject: [SC-L] Origins of Security Problems

Before widespread use of the Internet, computers were isolated from
malicious attacks.  Many of them were not networked.  CPUs were slow.
Memory was small.  It was common practice to "trust the user" to minimize
the size of programs to speed up processing and to make programs fit in
memory.  Non-typesafe languages permitted playing with the stack.  It
occurred to me repeatedly during that period that it would have been
extremely helpful if the compiler/runtime would have detected buffer
overflows.  Implementers always shot back that their prime concern was
minimizing path lengths (i.e. execution time) and that it was the
programmer's responsibility to guarantee buffer overflows would not occur.
With blunt instruments such as strcpy() and strcat() available to almost
guarantee occasional buffer overflows, and stacks arranged so that transfer
of control to malicious code could conveniently occur, it evidently doesn't
take a rocket scientist to figure out how to make a program misbehave by
providing invalid input that passes whatever passes for input validation.
Once code became mobile and access to vulnerable buffers became possible
over a wire, an epidemic of security breaches occurred.   Moreover, Internet
protocols were designed individually to provide a specific service.  Little
consideration went into how the protocols could be abused.   Computers are
now widespread and many of them today reside on the Internet with vulnerable
ports wide open.  The average computer owner doesn't know what a port is or
that it represents a potential avenue for abuse.  Software vendors remain
unmotivated to instruct owners as to what vulnerabilities exist and how to
minimize them because that would work against marketing and convenience.  A
small network desires file and printer sharing among the member computers.
Does this mean everybody on the Internet should have access to those files
and printers?  Of course not.  A standalone computer has the sharing port
wide open to the Internet because someday it might become a member of a
network.  Things have gotten better with additional features (e.g. Internet
Connection Firewall), default configurations set to res...