Lucene search
K

sendmail-x.x.x-DoS.txt

🗓️ 17 Aug 1999 00:00:00Reported by Packet StormType 
packetstorm
 packetstorm
🔗 packetstormsecurity.com👁 30 Views

Sendmail DoS vulnerability allows denial of service via SYN/RST attack exploiting connection refusal.

Code
`Date: Sun, 6 Sep 1998 00:53:24 +0200  
From: Michal Zalewski <[email protected]>  
To: [email protected]  
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 [[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: Sat, 31 Oct 1998 21:24:09 +1900  
From: Wietse Venema <[email protected]>  
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  
  
`

Data

Build on a solid foundation with Vulners data

We provide the essential building blocks for cybersecurity solutions with comprehensive, structured, and constantly updated vulnerability and exploits data

Api

Power your application with Vulners API

The Vulners REST API offers reliable, high-performance access to vulnerability intelligence, with 99.9% SLA uptime and CDN-backed data delivery for seamless global access

App

Assess and manage vulnerabilities with Vulners tools

Built on top of Vulners' database and SDK, end-user solutions give security professionals and developers lightweight and powerful tools for vulnerability remediation