`Date: Sat, 12 Dec 1998 02:22:10 +0100
From: Michal Zalewski <[email protected]>
To: [email protected]
Subject: Sendmail 8.8.x/8.9.x bugware
Bottoms up! Two bugs (and fixes) - Sendmail 8.8.x/8.9.x.
1. Redirection attack
Due to strange address parsing policy [briefly: if address ends with local
hostname, trim it and parse as any other (even if after this operation
address isn't 'local' anymore], specific message routing (eg. through
internal, protected or external networks) can be forced, giving an
occasion to perform anonymous scanning (or fakemailing). You could call it
'feature' instead of 'bug', but it seems to be Sendmail-specific ;>
Simple fix - in /etc/sendmail.cf, at the top of ruleset 98, insert
following line:
R$*@$*@$* $#error $@ 5.7.1 $: "551 Sorry, no redirections."
2. 'Headers prescan' DoS
There are possible DoS attacks due to ineffective headers prescan
algorithm. Two or three medium-size (200 kb) mail messages may render
system unusable for quite long period of time (as headers are parsed at
least twice, on message collection and in queue). Exploit sold separately
:-)
Simple patch for Sendmail 8.8.x source tree:
--- collect.c.orig Thu Dec 10 18:38:51 1998
+++ collect.c Thu Dec 10 18:53:02 1998
@@ -32,6 +32,8 @@
* SUCH DAMAGE.
*/
+#define MAXHDRZ 512
+
#ifndef lint
static char sccsid[] = "@(#)collect.c 8.72 (Berkeley) 10/6/97";
#endif /* not lint */
@@ -87,6 +89,7 @@
HDR **hdrp;
register ENVELOPE *e;
{
+ int hdrz=0;
register FILE *volatile tf;
volatile bool ignrdot = smtpmode ? FALSE : IgnrDot;
volatile time_t dbto = smtpmode ? TimeOuts.to_datablock : 0;
@@ -355,6 +358,17 @@
mstate = MS_BODY;
goto nextstate;
}
+
+ if (hdrz++>MAXHDRZ)
+ {
+ sm_syslog(LOG_NOTICE, e->e_id,
+ "excessive headers from %s during message collect",
+ CurHostName ? CurHostName : "<local machine>");
+ errno = 0;
+ usrerr("451 Stop this. You are lame.");
+ goto readerr;
+ }
+
/* check for possible continuation line */
do
_______________________________________________________________________
Michal Zalewski [[email protected]] [ENSI / marchew] [dione.ids.pl SYSADM]
[http://linux.lepszy.od.kobiety.pl/~lcamtuf/] <=--=> bash$ :(){ :|:&};:
[voice phone: +48 (0) 22 813 25 86] ? [pager (MetroBip): 0 642 222 813]
Iterowac jest rzecza ludzka, wykonywac rekursywnie - boska [P. Deutsch]
-------------------------------------------------------------------------------------
Date: Mon, 18 Jan 1999 10:12:21 +0100
From: Frank Louwers <[email protected]>
To: [email protected]
Subject: Re: Sendmail 8.8.x/8.9.x bugware
On Sat, 12 Dec 1998, Michal Zalewski wrote:
> On Sun, 17 Jan 1999, Alan Brown wrote:
>
> >> Bottoms up! Two bugs (and fixes) - Sendmail 8.8.x/8.9.x.
> > Michal, have you tested these against sendmail 8.9.2?
>
> Yes :-)
So have I ... It brings down everything, from DecStations running NetBSD,
over linux, to HP's running HPUX, all with the latest sendmail, and in all
the cases, sendmail died after 30 secs, and the load was very high ...
Frank
-------------------------------------------------------------------------------------
Date: Tue, 19 Jan 1999 14:02:12 -0800
From: Steve VanDevender <[email protected]>
To: [email protected]
Subject: Re: Sendmail 8.8.x/8.9.x bugware
Michal Zalewski writes:
> On Mon, 18 Jan 1999, Olaf Seibert wrote:
>
> > 550 <[email protected]@victim.some.where>... Relaying denied
>
> As you noticed, relaying is denied in your configuration ;P This attack is
> possible if relaying is enabled, and it allows multiple redirections
> trough protected or external networks, which shouldn't be allowed.
>
> For clearance - this problem IS PRESENT FOR SURE in 8.9.2, as well as DoS
> attack described in previous mail... If Sendmail developers don't believe
> me, I can post an exploit here, but iyt isn't really necessary, imho....
If you configure unrestricted relaying in sendmail 8.9, then
you've done something stupid anyway (and overridden the default
behavior).
You claim that this will fix the problem:
> Simple fix - in /etc/sendmail.cf, at the top of ruleset 98, insert
> following line:
> R$*@$*@$* $#error $@ 5.7.1 $: "551 Sorry, no redirections."
Unfortunately RFC 822 (and its followups) specify two kinds of
problematic accepted address formats:
user%host@relay
@relay:user@host
which both indicate that mail to user@host should be redirected
through relay (which may actually be a sequence of relays,
i.e. user%host%relay2@relay1 or @relay1,relay2:user@host).
Your "fix" would break at least the second format.
In any case, I can't perform the redirection that you claim is
possible in sendmail 8.9.2 configured with FEATURE(access_db); I
get the expected "550 Relaying denied" in a RCPT containing two
'@'s where the relaying would be through a domain not permitted
in the access file. Are you claiming this is possible in 8.9.2's
default configuration (which still limits relaying)?
`