sendmail-x.x.x-DoS.txt

1999-08-17T00:00:00
ID PACKETSTORM:15296
Type packetstorm
Reporter Packet Storm
Modified 1999-08-17T00:00:00

Description

                                        
                                            `Date: Sun, 6 Sep 1998 00:53:24 +0200  
From: Michal Zalewski <lcamtuf@IDS.PL>  
To: BUGTRAQ@netspace.org  
Subject: Sendmail, lynx, Netscape, sshd, Linux kernel (twice)  
  
// greetings to kotka :>  
// ...and everyone who could stand this post  
  
Hello boys and girls - probably everyone yearn after me :~( So I decided  
to publish some more or less recent stuff, and increase traffic on this  
beautiful list.  
  
Sendmail x.x.x DoS  
------------------  
  
Take a look at this piece of code (src/daemon.c):  
  
t = accept(DaemonSocket,  
(struct sockaddr *)&RealHostAddr, &lotherend);  
if (t >= 0 || errno != EINTR)  
break;  
}  
savederrno = errno;  
(void) blocksignal(SIGALRM);  
if (t < 0)  
{  
errno = savederrno;  
syserr("getrequests: accept");  
  
/* arrange to re-open the socket next time around */  
(void) close(DaemonSocket);  
DaemonSocket = -1;  
refusingconnections = TRUE;  
sleep(5);  
continue;  
}  
  
What we have here? Hmm, if accept() fails and syscall return code != EINTR,  
Sendmail writes warning message and refuses connections for 5 seconds.  
Hmm... Cute, isn't it?;> What about 'Connection reset by peer'?:) Our  
algorithm is simple:  
  
1. Send SYN from port X to victim, dst_port=25 (victim sends SYN/ACK)  
2. Send RST from port X to victim, dst=port=25 respecting sequence numbers  
(victim got error on accept() - and enters 5 sec 'refusingconn' mode)  
3. Wait approx. 2 seconds  
4. Go to 1.  
  
So, by sending just a few bytes every two seconds, we could completely  
lock sendmail service. There's no reason to post any exploits. RFC +  
any source (teardrop is good) + 'tcpdump -x' + 15 minutes = exploit.  
  
Solution: remove this stupid sleep(...), and probably whole if (t < 0)  
handler. Replace it with continue;  
  
_______________________________________________________________________  
Michal Zalewski [lcamtuf@ids.pl] [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: Sat, 31 Oct 1998 21:24:09 +1900  
From: Wietse Venema <wietse@PORCUPINE.ORG>  
Subject: Re: Sendmail, lynx, Netscape, sshd, Linux kernel (twice)  
  
Michal Zalewski:  
> 1. Send SYN from port X to victim, dst_port=25 (victim sends SYN/ACK)  
> 2. Send RST from port X to victim, dst=port=25 respecting sequence numbers  
> (victim got error on accept() - and enters 5 sec 'refusingconn' mode)  
> 3. Wait approx. 2 seconds  
> 4. Go to 1.  
>  
> So, by sending just a few bytes every two seconds, we could completely  
> lock sendmail service. There's no reason to post any exploits. RFC +  
> any source (teardrop is good) + 'tcpdump -x' + 15 minutes = exploit.  
  
This attack is specific to LINUX. On UNIX systems with a BSD TCP/IP  
protocol stack, the accept() call does not return until the three-way  
handshake completes.  
  
Please do not blame Sendmail for every problem in the world.  
  
Wietse  
  
`