Onderwerp: possible open relay hole in qmail-smtpd-auth patch

--Boundary-02=_61CF/fS8eBwGEmA
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Description: signed data
Content-Disposition: inline

the qmail-smtpd-auth patch is a commonly used patch to qmail which allows=20
the qmail-smtpd program to support the AUTH extension, by specifying a=20
"checkpassword" program on the command line. the homepage for the patch is:

http://members.elysium.pl/brush/qmail-smtpd-auth/

the patch modifies qmail-smtpd so that it can be called with three=20
command-line parameters: the local host name (used for generating CRAM-MD5=
=20
challenges), the checkpassword program itself, and a "dummy" program which=
=20
is run by the checkpassword program after a successful authentication.

the "dummy" program is needed because checkpassword programs are designed=20
for use in a POP3 or IMAP situation, where they would validate the user's=20
credentials and then run the actual POP3 or IMAP server program.

the current version of the SMTP-AUTH patch contains a serious bug which can=
=20
accidentally allow somebody who forgets one or more of the command line=20
parameters to start running an open relay by accident. it has been reported=
=20
in several places over the last week, including this message on the qmail=20
mailing list:

http://marc.theaimsgroup.com/?l=3Dqm...74430616&w=3D2

if the user forgets the hostname parameter to qmail-smtpd and uses /bin/tru=
e=20
as the dummy program (/bin/true is the suggested dummy program), they will=
=20
actually be using /bin/true as the checkpassword program, which allows ANY=
=20
combination of userid and password to use your server as a relay.

i have written a revision to the qmail-smtpd-auth patch which compensates=20
for this common error by not supporting the AUTH command unless all three=20
command line arguments are present.

the version 0.31 patch does not correctly check for this- with a missing=20
command line argument, it ends up reading memory beyond the end of argv[],=
=20
which is NOT filled with zeros- on most *nix systems it's actually the=20
beginning of the environment block.

http://www.jms1.net/qmail/ has the modified "auth.patch" file available for=
=20
download.

the changes i've made (actually CHECKING argc instead of assuming there wil=
l=20
be something there) need to be incorporated into the qmail-smtpd-auth patch=
=20
as soon as possible. the author of the patch seems to have not touched it=20
since may 2002.

=2D-=20
=2D----------------------------------------------
| John Simpson - KG4ZOW - Programmer At Large |
| http://www.jms1.net/ <jms1@jms1.net> |
=2D----------------------------------------------

--Boundary-02=_61CF/fS8eBwGEmA
Content-Type: application/pgp-signature
Content-Description: signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQA/FC16EB9RczMG/PsRAjIbAKCSlYaV0RHp5FiPR7tr8TkPdqFwjgCghI6K
toVFSvpC/vrSVDADRX58N4o=
=/6Zb
-----END PGP SIGNATURE-----

--Boundary-02=_61CF/fS8eBwGEmA--

On Tue, Jul 15, 2003 at 12:36:05PM -0400, John Simpson wrote:

> the current version of the SMTP-AUTH patch contains a serious bug which can
> accidentally allow somebody who forgets one or more of the command line
> parameters to start running an open relay by accident. it has been reported
> in several places over the last week, including this message on the qmail
> mailing list:

A possible configuration problem is NOT a reason to disallow legitimate
configurations or to enforce the use of useless dummy arguments, and
unless you are going to invent some kind of artificial intelligence
inside tools or installers using checkpassword i request that you
stop this.


While the usual usage of checkpassword is something like this
tcpserver host port prog1 [args] checkpassword prog2 [args]
there is no reason why one has to call it that way. One may replace
the part starting from "checkpassword" by a wrapper (this may be
especially handy to add logging, to try more than one checkpassword
style program or when one has to use different "tcpserver...prog1"
combinations all sharing identical later commandline arguments -
i've seen this being used).
Cluttering the commandline with "dummy-argument-for-stupid-patches"
or whatever is not going to do any good, is not looking good, and
does not add any security at all.


In fact, someone stupid enough to patch qmail without understanding
the patch and stupid enough to ignore vital parts of it's
documentation (the examples, at least) is likely to be stupid
enough to change the order of checkpassword and /bin/true, too.
Are you now going to patch /bin/true to bail out in case it finds
commandline arguments?


> http://www.jms1.net/qmail/ has the modified "auth.patch" file available for
> download.

please? Are you seriously expecting that this:
+ if(argc > 2)
+ {
+ hostname = argv[1];
+ childargs = argv + 2;
+ useauth = 1;
+ }
will work?

Hint: when called "qmail-smtpd HOST CHECKPASSWORD" argc will be 3.
I'd call this a beginners mistake, but even beginners are supposed
to test their code.


> the changes i've made (actually CHECKING argc instead of assuming there will
> be something there) need to be incorporated into the qmail-smtpd-auth patch

i suggest you start "CHECKING" your code.

While i'm at it: Your qmail-1.03-jms1-antispam.patch not only violates
the SMTP protocol (replying OK when the mail will definitively not reach
the recipient) but does that in case of almost any programming or
configuration problem in the filter chain, causing shell/filters to
exit with 1.
Why the heck did you change exit code 1 from "temporary problem,
try again later" to "throw away that mail"? Why do you actually
run a smtp server if your mail is worthless?

Regards, Uwe

--==_Exmh_-848528712P
Content-Type: text/plain; charset=us-ascii

On Wed, 16 Jul 2003 11:54:18 -0000, Uwe Ohse <uwe@ohse.de> said:

> While i'm at it: Your qmail-1.03-jms1-antispam.patch not only violates
> the SMTP protocol (replying OK when the mail will definitively not reach
> the recipient

Actually, it is *quite* legal to reply a '250 OK' on something that will eventually
bounce. If it weren't, you couldn't have an MX site that had no direct knowledge of
all possible valid userids (think about it - your main mail hub goes down, mail
starts piling up at your off-site backup MX - and THAT mail server has to say
'250 OK' without being able to tell for *SURE* that 'userid@ohse.de' is or is not valid.

RFC2821, section 6.1 says:

6.1 Reliable Delivery and Replies by Email

When the receiver-SMTP accepts a piece of mail (by sending a "250 OK"
message in response to DATA), it is accepting responsibility for
delivering or relaying the message. It must take this responsibility
seriously. It MUST NOT lose the message for frivolous reasons, such
as because the host later crashes or because of a predictable
resource shortage.

If there is a delivery failure after acceptance of a message, the
receiver-SMTP MUST formulate and mail a notification message. This
notification MUST be sent using a null ("<>") reverse path in the
envelope. The recipient of this notification MUST be the address
from the envelope return path (or the Return-Path: line). However,
if this address is null ("<>"), the receiver-SMTP MUST NOT send a
notification. Obviously, nothing in this section can or should
prohibit local decisions (i.e., as part of the same system
environment as the receiver-SMTP) to log or otherwise transmit
information about null address events locally if that is desired. If
the address is an explicit source route, it MUST be stripped down to
its final hop.

So it's perfectly valid to issue a 250 OK for a bad address, as long as
you bounce it if there's an issue later.


--==_Exmh_-848528712P
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Exmh version 2.5 07/13/2001

iD8DBQE/FboScC3lWbTT17ARAqdaAKCE/61cEkf9XHi8eMXat3H1g/SxgwCg1//d
lCq0/jo59H21t/Zm5LOzhQ0=
=MH+s
-----END PGP SIGNATURE-----

--==_Exmh_-848528712P--

JS> i have written a revision to the qmail-smtpd-auth patch
JS> which compensates for this common error by not supporting
JS> the AUTH command unless all three command line arguments
JS> are present.

You've no guarantee that 3 is the correct number. An administrator might
decide to use

qmail-smtpd domain checkpassword /bin/echo Hello there.

rather than

qmail-smtpd domain checkpassword /bin/true

for example, just for the heck of it.

If you are about to assert that "The number of arguments is always going to be
exactly 3 because 'checkpassword' is always going to be given just the one
argument, '/bin/true'.", then I suggest that you consider taking that fact
into account in the design of your modified patch, and eliminate the scope for
variation in something that you are asserting is in fact intended to be
constant.

On Wed, Jul 16, 2003 at 04:48:18PM -0400, Valdis.Kletnieks@vt.edu wrote:

> Actually, it is *quite* legal to reply a '250 OK' on something that
> will eventually

the patch (qmail-1.03-jms1-antispam.patch) replies with 250, even though
it already knows that the message will _not_ reach the recipient and
will _not_ be bounced. It knows that the message is being sent to
/dev/null.

Sorry for being unclear.

Regards, Uwe