Date:         Thu, 13 Jan 2000 09:14:55 -0800
From: Gregory Neil Shapiro <sendmail+gshapiro@SENDMAIL.ORG>
Subject:      Re: procmail / Sendmail - five bugs
To: BUGTRAQ@SECURITYFOCUS.COM

-----BEGIN PGP SIGNED MESSAGE-----

lcamtuf> a) Sendmail (tested with 8.9.3 and previous) allows you to put
lcamtuf>    mail addressed to eg. '|/bin/sh' (or any file) into mail
lcamtuf>    queue. Fortunately, this queue file should contain also line
lcamtuf>    like 'Croot' to be processed properly, while we have no idea
lcamtuf>    how to put it there. But, anyway, seems to be dangerous -
lcamtuf>    Sendmail should reject such crap immediately:

lcamtuf>    /usr/sbin/sendmail -O 'DeliveryMode=d' '""|/bin/sh'

lcamtuf>    (without these double-quotes, it _will_ immediately drop your
lcamtuf>    message)

As you have noted, this appears only to be possible with an outdated .cf
file and an 8.9.3 binary.  However, even in this case, the address is not
accepted as there isn't a valid controlling user.  We have run through the
possible scenarios we could find and do not believe this to a threat.
Also, as people upgrade their binaries, they should upgrade their
configuration and this should not be an issue.

lcamtuf> b) Into queue files (qf*), Sendmail stores internal delivery
lcamtuf>    information, user-supplied headers (Hxxx) and server-added
lcamtuf>    headers (H?x?xxx). These headers are handled in several
lcamtuf>    different ways, depending on letter between '?' - but, in
lcamtuf>    general, are used to store default values for other headers
lcamtuf>    (like 'Date:' and 'Return-Path:'). But, headers like:

lcamtuf>    ?D?My-Own-Header: junk

lcamtuf>    are allowed in messages, and are put in unchanged form into
lcamtuf>    queue files, allowing possible conflicts or MTA confusion :P
lcamtuf>    For example, header '???This-Causes-Error: test' causes odd
lcamtuf>    error messages during message processing. What does it mean?
lcamtuf>    Probably nothing dangerous, but I haven't spend enough time
lcamtuf>    investigating this issue to be sure, maybe it's some way to
lcamtuf>    cause undesirable MTA behaviour.

Agreed, this is a bug.  The next beta version of 8.10.0 will not have this
problem.  Given this isn't a security problem, it will not be fixed for
8.9.3.

lcamtuf> c) Sendmail won't put X-Authentication-Warning header (eg. about
lcamtuf>    protocol violations, suspected options etc) into message if
lcamtuf>    there's one already present - no matter how stupid it is. Minor
lcamtuf>    bug.

This is also fixed in the next beta version of 8.10.0.

lcamtuf> So, another thing. There's nice remote Sendmail ETRN DoS. When
lcamtuf> ETRN command is read by Sendmail (it shouldn't be allowed at all,
lcamtuf> IMHO), it calls fork(). Parent process generates no output - only
lcamtuf> child-generated output is sent, so parent won't be notified on
lcamtuf> send()/write() failure. If we drop connection (after sending a lot
lcamtuf> of ETRNs), parent process will stuck, doing repeately fork()
lcamtuf> ... sleep(5), till end of ETRNs read into input buffer is
lcamtuf> reached. This allows us to spawn any amount of 'unusable' sendmail
lcamtuf> childs, hanging for long period of time - and it can be done using
lcamtuf> low network bandwitch and resources. Direct result - all server
lcamtuf> memory consumed (causing Linux 2.0 kernels to crash with messages
lcamtuf> like 'no memory for sendmail', 'no memory for klogd' etc). Unlike
lcamtuf> connect() flooding, this attack is generating low traffic, only
lcamtuf> one connection at time, and seems to be deadly harmful, unless
lcamtuf> something like:

lcamtuf> # maximum number of children we allow at one time
lcamtuf> O MaxDaemonChildren=15

Yes, MaxDaemonChildren will avoid this sort of denial of service attack.
However, the fact that sendmail buffers up commands after a remote side
drops its connection is a bug.  This bug will be fixed in the next 8.10.0
beta release.

Once again, thanks for bringing these bugs to our attention.

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.0 for non-commercial use
Comment: Processed by Mailcrypt 3.5.5, an Emacs/PGP interface
Charset: noconv

iQCVAwUBOH4H/XxLZ22gDhVjAQH2jwP9HuMCOdSuROR1E5VFUIp+s+6TtGALNzh3
1tkO2L8LYav2FztbYQjI3kjdCAcocGZGW6k6vKoxU4b/3Y6Z/rEVs6QWTLick4Ei
uVk8ZIrq0Br4s4XEZg1V3x1U0Ex+1KPmlLmDqRyJYUio3wPV0Zie0CHbzAKavUlH
q5ze6Hq/m6k=
=955/
-----END PGP SIGNATURE-----