RE: Origins of Security Problems

["Dave Paris" <dparis () w3works com>]

Following the logic in the original post...

God is love.
Love is blind.
Ray Charles was blind.
Ray Charles was god.


The origins of security problems are simply based in the designers of the
systems.  Humans, on the whole, are a fallible lot.  We're not perfect and
when we design systems, it's quite conceivable that in some cases we simply
cannot account for all possibilities - aka "the imperfection shows through".
The better of us bipeds can get close to creating an actually secure system,
but the bulk of us simply do the best we can and sometimes it works out,
other times it doesn't.

Kind Regards,
-dsp

> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Behalf Of Mark Rockman
> Sent: Tuesday, June 15, 2004 1: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 restrict not for
> convenience, and anti-virus software.  The origin of security
> problems lies
> in widespread Internet usage and habitual lack of effort to ensure that
> programs don't do things that owners don't want them to do.