Re: sendmail 8.12.8 available

[Florian Weimer]

Claus Assmann <ca+bugtraq@sendmail.org> writes:

> Sendmail, Inc., and the Sendmail Consortium announce the availability
> of sendmail 8.12.8. It contains a fix for a critical security
> problem discovered by Mark Dowd of ISS X-Force; we thank ISS X-Force
> for bringing this problem to our attention. Sendmail urges all users to
> either upgrade to sendmail 8.12.8 or apply the patch for 8.12 that
> is part of this announcement.

Would people be willing to share filter rules for other MTAs to block
offending messages on relays?

Thanks,
--
Florian Weimer Weimer@CERT.Uni-Stuttgart.DE
University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/
RUS-CERT fax +49-711-685-5898

[Mordechai T. Abzug]

On Mon, Mar 03, 2003 at 09:08:09AM -0800, Claus Assmann wrote:

> 8.12.8/8.12.8 2003/02/11
> SECURITY: Fix a remote buffer overflow in header parsing by
> dropping sender and recipient header comments if the
> comments are too long. Problem noted by Mark Dowd
> of ISS X-Force.
> Fix a potential non-exploitable buffer overflow in parsing the
> .cf queue settings and potential buffer underflow in
> parsing ident responses. Problem noted by Yichen Xie of
> Stanford University Compilation Group.

Question: are the header and ident issues *only* remote overflow
problems, or is this also a local vulnerability? Ie. if one has a
system that doesn't run sendmail in daemon mode (-bd), but does make
sendmail available as an SUID root binary for submission to the local
smarthost and does run sendmail is queue-process mode (ie. -q15m), is
the system still vulnerable? Given that the problem is in the header
parsing, I would expect this to be both a remote and a local problem,
but I'd like to make sure before doing lots of upgrades.

Thanks.

- Morty

[Nico Erfurth]

Florian Weimer wrote:
> Claus Assmann <ca+bugtraq@sendmail.org> writes:
>
>
>>Sendmail, Inc., and the Sendmail Consortium announce the availability
>>of sendmail 8.12.8. It contains a fix for a critical security
>>problem discovered by Mark Dowd of ISS X-Force; we thank ISS X-Force
>>for bringing this problem to our attention. Sendmail urges all users to
>>either upgrade to sendmail 8.12.8 or apply the patch for 8.12 that
>>is part of this announcement.
>
>
> Would people be willing to share filter rules for other MTAs to block
> offending messages on relays?
>
> Thanks,

I'm not sure how the exploit works, but if I understood the LSD-analysis
correctly, it uses the comment for the payload, and needs many <> in a
parsed header. With exim4, this ACL should/could help.

First it checks for the header-syntax, that will reject the <><><><>
used in the LSD-POC-code. The second condition should refuse to accept
comments longer than 20 chars.

acl_data = check_message

check_message:
require message = Invalid header syntax (Maybe sendmail exploit)
verify = header_syntax
deny message = Ohh, this looks like the sendmail-exploit
condition = ${if match {$h_from: $h_cc: $h_bcc: $h_reply_to: \
$h_sender: $h_to:} {\N\(.{21,}?\)\N}{1}{0}}


No warranty ;)

Nico Erfurth

[Neil W Rickert]

"Mordechai T. Abzug" <morty@frakir.org> wrote:

>Question: are the header and ident issues *only* remote overflow
>problems, or is this also a local vulnerability? Ie. if one has a
>system that doesn't run sendmail in daemon mode (-bd), but does make
>sendmail available as an SUID root binary for submission to the local
>smarthost and does run sendmail is queue-process mode (ie. -q15m), is
>the system still vulnerable? Given that the problem is in the header
>parsing, I would expect this to be both a remote and a local problem,
>but I'd like to make sure before doing lots of upgrades.

I don't think there has been a comment on this yet.

Sendmail will only use "ident" when receiving mail on a network
connection. There is no local exploit available there if sendmail is
not listening on the net. Possibly a local user could invoke
"sendmail -bs" with stdin/stdout assigned to a connected socket. In
that case there might be an ident call.

For the header problem, any buffer overflow would occur while sending
the message, not while receiving it. Whether the message originated
locally or over the network will matter. Thus there is a potential
problem for local exploits with an SUID sendmail binary.

In particular, if you have old sendmail binaries left around that you
haven't deleted, you should at least turn off any SUID and SGID
privileges. Incidently that's a good practice for old disused
versions of any program.

-NWR

[Bennett Todd]

--Qrgsu6vtpU/OV/zm
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Mon, 3 Mar 2003, Florian Weimer wrote:
> Would people be willing to share filter rules for other MTAs to
> block offending messages on relays?

Wietse Venema offered the following responses for Postfix. First out
of the gate was [1], this regexp-based quick-response; capable of
false-positives, but not as scary as might be feared since it only
looks in the headers (place this in a regexp map, assign that to
header_checks):

/<><><><><><>/ reject possible CA-2003-07 sendmail buffer overflow exploit

Then he came out with [2], a new release of postfix with
functionality like that of patched sendmail, sanitizing messages
as they pass through and logging when it does so. This enhancement
he then broke out as a light patch [3] to apply against most
versions of postfix that might be in use, for people who'd like the
protection without having to upgrade to a newer version.

To be clear here: Postfix is not itself susceptible to this problem.
The only purpose for this patch is to allow Postfix to mung messages
to protect vulnerable sendmails downstream from it.

-Bennett

[1] <URL:http://archives.neohapsis.com/archives/postfix/2003-03/0254.html>
[2] <URL:http://archives.neohapsis.com/archives/postfix/2003-03/0402.html>
[3] <URL:http://archives.neohapsis.com/archives/postfix/2003-03/0487.html>

--Qrgsu6vtpU/OV/zm
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE+aPfHHZWg9mCTffwRAkilAKDGdcDTBxEuXLsfY8VKZj raidKaUgCgmdyN
6s6HdnpPgd3v4vNd1TRgt7A=
=pQQY
-----END PGP SIGNATURE-----

--Qrgsu6vtpU/OV/zm--