On Tuesday 17 July 2001 06:28, you wrote:
> 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?
nessus points this out as a security hole.....
--
You can get my public pgp key here:
http://foobar.gmxhome.de/joachim.txt
