mailing list archives
Re: Possible local DoS in sendmail
From: gshapiro () SENDMAIL ORG (Gregory Neil Shapiro)
Date: Fri, 2 Apr 1999 10:23:26 -0800
-----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
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
-----END PGP SIGNATURE-----