[3382] in WWW Security List Archive
Re: www web security !
daemon@ATHENA.MIT.EDU (Harry Mantakos)
Fri Oct 25 18:36:27 1996
To: ley@cert.dfn.de (Wolfgang Ley)
cc: www-security@ns2.rutgers.edu
In-reply-to: Your message of "Fri, 25 Oct 1996 19:01:27 +0200."
<199610251701.TAA11350@tiger.cert.dfn.de>
Date: Fri, 25 Oct 1996 16:05:15 -0400
From: Harry Mantakos <harry@tis.com>
Errors-To: owner-www-security@ns2.rutgers.edu
>I'm not aware of any attack that will work against up-to-date sendmail
>versions but will be prevented by using smap. smap only changes direct
>SMTP remote access to sendmail to an indirect way. So what does this
>help you? ...
What is your list of attacks that will work against up-to-date
versions of sendmail? It seems to me that you're saying
that smap only protects you against holes in sendmail that have
already been fixed, but it appears to me that _all_ publicly
known holes in sendmail have been fixed, at least until the next
hole is made public.
The idea behind smap/smapd is to try to do the most prudent thing
that you can do with email, while still allowing as a necessity
that you'll somehow eventually have to hand off the message to
a complex tool like sendmail so it can deliver it (which is presumably
a complex task).
The smap/smapd combo gets you a few things:
- the "thing" that does the smtp exchange is small and simple,
and written with security in mind. Its job is just to collect
an email message over smtp and stuff it into a file. Since this
requires no special privileges (assuming 'inetd' hands you
port 25), it can run under an unprivileged uid and can be
run chrooted. It similarly doesn't bother with "questionable"
sendmail features like doing ident lookups (another old
"fixed" sendmail hole). It only supports the minimal subset
of smtp commands needed to pass around email messages, no
'expn' or 'vrfy' (or 'debug' :) .
- smapd parses the message and checks for things like suspicious
characters in addresses (e.g. '/' and '|') You can say that this
class of sendmail holes have all been closed, and maybe they
have, but I'll also point out that over the years there were
several iterations of fixes to eradicate a number of "filenames
in addresses" holes, and we could have said "that's fixed" after
iterations 1 or 2 and been proven wrong at iteration 3.
smapd also enforces maximum header line lengths.
- when smapd hands the message off to sendmail, it is presumably
running on a firewall that doesn't require local delivery of
messages and that doesn't need the ability to bind to port 25,
and as such only needs to be able to read the queued message and
forward it to another mail server. This allows you to run sendmail
itself under an unprivileged uid. This is pretty important,
because even if you come up with a good data-driven sendmail
attack, you're still looking at having subverted a process with
little privilege.
Trying to predict the next hole in sendmail is tough, so obviously
smap/smapd can't detect them all. The idea is just to do the few
very prudent things that you can do to protect yourself. Does
this mean you can run sendmail version 5 and be blissfully unconcerned
forever? Nope.
-harry
p.s. Yes, I know, this has nothing to do with www-security, how
did we start talking about this any way?
--------------------------------------------------------------------------
Name: Harry Mantakos Email: harry@tis.com Phone: 301-947-7145
USPS: Trusted Information Systems, 15204 Omega Drive, Rockville, MD 20850
