On Mon, Jul 16, 2001 at 04:48:37PM -0700, Hank Wethington wrote:
[ran tests on qmail, wants insight into the results]
> 1)The remote STMP server seems to allow remote users to
> send mail anonymously by providing a too long argument
> to the HELO command (more than 1024 chars).
> 
> This problem may allow bad guys to send hate
> mail, or threatening mail using your server
> and keep their anonymity.

Presumably the vulnerability scanner considers this a problem because
some MTA has a fixed space buffer for the Received: header, and if the
HELO argument is too long it leaves insufficient room in the buffer
for the sender IP and timestamp, which come after the HELO argument.
Note that this problem has little to do with buffer overflows; even
if proper bounds checking is done it still leaves insufficient space
for the additional information.

qmail has no such problems. For qmail-smtpd, commands.c is the first
stop for input from HELO. commands() in commands.c  saves the HELO
argument into a dynamically allocated string using stralloc, calling
die_nomem() if it runs out of memory. In other words, if qmail-smtpd
doesn't abort for lack of memory, the argument is stored in its
entirety.

The next stop for the HELO argument is smtp_helo() in
qmail-smtpd.c. It sends a 250 response to the client.

Then the argument is passed to dohelo() in qmail-smtpd.c. It is copied
into an stralloc string, again calling die_nomem() if stralloc
fails.

When it comes time to generate the Received: line, qmail-smtpd has
spawned qmail-queue, which should be ready to pass the message through
to a queue file. received() in received.c passes each part of the
Received: line to a buffer layer, effectively causing the HELO
argument to go straight through qmail-queue into the queue file.

qmail-smtpd will reliably handle any length HELO argument up to the
limits of memory, and if it runs out of memory it aborts the
transaction entirely.

> 2)The remote SMTP server is vulnerable to a redirection
> attack. That is, if a mail is sent to :
> 
>               user@hostname1@victim
> 
> Then the remote SMTP server (victim) will happily send the
> mail to :
>               user@hostname1
> 
> Using this flaw, an attacker may route a message
> through your firewall, in order to exploit other
> SMTP servers that can not be reached from the
> outside.

This is covered in the archives.

What vulnerability scanner are you using?

Reply via email to