Lucene search

K
packetstormPacket StormPACKETSTORM:12374
HistoryAug 17, 1999 - 12:00 a.m.

sendmail-8.8.x-8.9.x.txt

1999-08-1700:00:00
Packet Storm
packetstormsecurity.com
19
`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)?  
  
`