A denial of service is any action that leads legitimate users to be denied access to services to which they are entitled. Servers have finite capacity, and are therefore inherently vulnerable to denial of service. For example, if a user hogs all available connections to an email server, then others will be unable to send email.
Completely eliminating such attacks is impossible. It is possible to mitigate and shift the damage, but there is no technical way in which legitimate users can be served while all illegitimate users are denied.
The following are the approaches that might be tried to mount a DoS attack on a qmail server running qscanq. Some of these attacks are covered by the qscanq security guarantee, and some aren't.
- Killing the virus scanner
The virus scanner runs with the credentials of the caller--a local user if qmail-inject is used, and qmaild if qmail-smtpd is used. A local user can DoS himself by killing all running instances of antivir. A remote user must achieve qmaild credentials in some way to kill the scanner while it processes remote messages.
The effect of killing the scanner is to cause the email to be temporarily deferred: the sender should try sending it again. A user would need to kill the scanner on every attempt over qmail's QUEUELIFETIME for the message to bounce permanently.
If some bug or security hole in qscanq allows local or remote users to kill the virus scanner for emails not belonging to them, then this bug is covered under the qscanq security guarantee. Note that killing the ripmime process that extracts the parts of an email, counts as "killing the virus scanner".
Some email client software, such as Mew, commits two sins: first, it thinks it's an MTA and sends emails via SMTP; second, it doesn't look at error codes. As a result, killing the scan process will cause Mew to throw the message away. This is a Mew bug, and is not covered under the qscanq guarantee.
- Killing qscanq itself
Qscanq runs as the qscanq user. If it is killed, email will be deferred just as in the previous example, killing the virus scanner. To kill qscanq requires exploiting a bug in qscanq itself, or gaining qscanq's user privileges and killing the process. Any bug in qscanq that permits qscanq to be killed while handling messages (other than the message containing the exploit itself, if any) is covered by the qscanq guarantee.
- Filling up the disk
The cleanq process deletes old message pieces and leftover files from scanning a message. If cleanq can be prevented from running, killed, or otherwise subverted, then messages will accumulate until performance slows to a crawl, and eventually the disk fills up. The cleanq process runs as the qscanq user; subverting the process involves either exploting a bug in cleanq itself, or a bug in qscanq, or in achieving elevated privileges. If any of these attacks can be performed due to qscanq bugs, then the qscanq guarantee applies.
An alternate way to defeat cleanq is to create folders in the scanning spool. Since the scanner runs as the caller, those folders can be made undeletable to cleanq, which will cause buildup in the spool folder. To do this requires that either ripmime or antivir be compromised, since neither creates folders. Such a compromise is not covered by the qscanq security guarantee, but I want to know about it.
- Hogging the CPU
Attempting to hog the CPU should be impossible beyond the ways in which this can be done without qscanq installed. Calling run-cleanq repeatedly is an inefficient way to hog the CPU, and calling other standard tools repeatedly (such as find, or dd) would be more effective. The cleanq script pauses for a specified interval (default: 10 seconds) before running through the spool folder, so that invidividual runs will be more efficient on a heavily-loaded server. During that interval, further calls to run-cleanq are ignored by the supervise process.
