Re: EMERGENCY: new remote root exploit in UW imapd

[dossy () PANOPTIC COM (Allanah Myles)]

On 1998.07.20, Brett Lymn <blymn () BAEA COM AU> wrote:
> A sufficiently determined programmer can write crap code despite the
> language.

This is the key issue with the inherent security problems.  The
collolary to this statement is "better tools allow bad programs to
implement bad designs faster."  Using "better tools" as others seem
to suggest will *not* gain us any more "security" than we already
have, if we don't also change the quality of programmers.  Yes,
some people believe Eric Allman is a "good" programmer.  And, as
someone replying to this list has said, "10,000 lemmings can't
be wrong."  The problem is not in the implementor, nor the
implementation, but elsewhere.

The real problem in system security really comes from the flawed
design from which software is implemented from (or worse, no
real design at all).  I recall someone on this list as saying,
"user programs are meant to be user-friendly, secure programs
are meant to be secure."  This is a very clever way of indicating
the necessary focus of the two classes of software.  To clearly
restate, "privilaged programs should be simple in design and
implementation; they should do one thing, and do it well."

In this particular case of imapd, the blame doesn't lie upon
the programmers nor the tools they used, but more the design
itself.  Why in god's name should a mail system require
system-wide root privilages?  As a normal user, I should be
able to manipulate my own mailbox.  Why shouldn't the agent
through which I manipulate my own mailbox run, from start
to finish, with no more privilages than my own user?  And,
for the section that *must* have extra-privilaged execution,
keep it so simple that one could easily hand-trace it's
execution and guarantee some comfortable level of safety.
If one can't envision a design that follows this practice,
that is where the blame should lie. "Tools don't produce bad
software. Bad designers produce bad designs from which bad
software is implemented."

In developing new "secure systems," we should spend less time
*securing* already existing insecure systems, in the hopes
of deluding ourselves that they have somehow become "secure"
(when we know we can never prove such a thing).  We should
instead focus our energies on designing software systems
where the threat-level is as minimal as possible.  This
still won't prevent lost work and other problems, but if
this is a significant issue, why does a tool like "rm"
exist?  Yes, in the wrong hands, "rm" can be very devastating.
But, without necessary privilages, the scope of the damage
is much smaller.  So, design tools that do not require
unnecessary privilages, and focus on preventing unauthorized
gain of those privilages.  Don't work the other way around,
letting software run with privilages and simply trying to
make them behave perfectly.  That's a much harder task.

The traditional argument is that "with the way things
currently are, it may be nearly impossible to redesign
services to not require privilages."  Well, then, if
you want a secure system, be prepared to build one---from
scratch, if need be.  Perhaps even the existing notion of
UNIX-based privilages is insufficient for any real
security - design a better model, and implement it.
Don't complain about the tools people choose to use,
as changing those won't improve security, they'll just
give us new types of security problems to find.

-Dossy

--
URL: http://www.panoptic.com/~dossy -< BORK BORK! >- E-MAIL: dossy () panoptic com
    Now I'm who I want to be, where I want to be, doing what I've always said I
    would and yet I feel I haven't won at all...      (Aug 9, 95: Goodbye, JG.)
"You should change your .sig; not that the world revolves around me." -s. sadie