don't assume stuff is safe (was Re: blowchunks)

From: Perry E. Metzger (perry@piermont.com)
Date: 06/22/02 

To: c.bailiff+blowchunks@devsecure.com
From: "Perry E. Metzger" <perry@piermont.com>
Date: 22 Jun 2002 15:45:37 -0400

Cris Bailiff <c.bailiff+bugtraq@devsecure.com> writes:
> Because apache is so great, and has had a history of very few serious
> security bugs, older versions are embedded in a wide variety of
> products and systems,

(Not in any way criticizing your "blowchunks" work -- just using this
as a jumping off point...)

This has always been a mistake. Apache is a nice program designed by
good people, but it was never designed with security in mind. Indeed,
most systems are not designed with security in mind. A few systems
have been -- postfix and qmail for example -- but for the most part,
raging paranoia is the only way to treat software. Just because it
doesn't have a bad record doesn't mean someday someone isn't going to
crack it like an egg.

Design for security, folks. Just because the ostrich can't see the
predator doesn't mean it isn't there. Don't trust your
servers. Someday they'll be cracked. If you're a vendor, assume your
software can be attacked and make sure it won't cause much harm when
it is. If you don't know how to do that, study programs done by people
who do. That also means don't design systems so they can't be
upgraded.

If you're a user, design your networks and your business processes on
the assumption that portions of a system can and will be compromised
someday.

By the way, hats off to Niels Provos for his recent work on systrace
in OpenBSD (recently ported to NetBSD) -- it is a subsystem that lets
you go beyond just chrooting a vulnerable server and actually say
"this program isn't allowed to run fork or exec or open a file for
write" and such, thus preventing exploits from being able to do very
much once they've taken over a vulnerable server process. Not
foolproof, but certainly an excellent tool in a world where product
vendors spend so rarely design for security.

Perry

Relevant Pages

  • Re: Security and EOL issues
    ... OS software resources are designed that reserved ram and disk space among other resources, to reflect what current hardware size is available. ... (There was a security patch a few years ago that could not be applied to NT4 as it required more resources then NT4 could provide. ... Installing air bags requires that the automobile manufacturer design, test, ... Computer Emergency Response Teams, and Digital Investigations. ...
    (Security-Basics)
  • Re: I need a system the U.S. government cannot hack
    ... By way of a further excuse, using words such as 'hack', 'government' or ... The security requirements are driven in part by the costs associated with ... The bulk of the cost of box and wire systems is in the infrastructure --> ... While I can, and will, and am trying, to move ahead with my own design, ...
    (microsoft.public.security)
  • Re: I need a system the U.S. government cannot hack
    ... By way of a further excuse, using words such as 'hack', 'government' or ... The security requirements are driven in part by the costs associated with ... The bulk of the cost of box and wire systems is in the infrastructure --> ... While I can, and will, and am trying, to move ahead with my own design, ...
    (microsoft.public.security)
  • Re: Well Andrew, "3" count them "3" security patches for VMS in five
    ... Whenever you discuss security with VMS guys ... be a fully patented methodology by OpenVMS Engineering. ... calling standard which rules out "by design" the primary cause of ... - design privilege assignments to be attached to a mode. ...
    (comp.os.vms)
  • Re: Microsoft finally acknowledges the security drumbeats
    ... > was formerly in charge of design for VMS (a quite securely designed OS, ... intel/alpha/mips/powerpc) and easy security audit (which is no more: ... Even Ford doesn't give you a whole new car when they issue ... Here comes the fact of management taking "technical" ...
    (comp.security.unix)