feh at fehcom
Jun 1, 2011, 1:28 PM
Post #1 of 1
(816 views)
Permalink
|
|
Re: STARTTLS vulnerabilty and qmail-spamcontrol ucspi-ssl qpsmtpd
|
|
On Wed, 01 Jun 2011 21:03:51 +0200, Graham Todd <gtodd [at] iciti> wrote:
Hi Graham,
> Hi I'm a user of the qpsmtpd and qmail-spamcontrol ports on FreeBSD
> (garga [at] FreeBSD is the qmail-spamcontrol port maintainer), thanks to
> you all for making qmail even more excellent by integrating all the
> patches and making it easy to build and install on FreeBSD and using
> perl to make it as flexible as Apache ;-)
>
> As I understand it STARTTLS support in qmail-spamcontrol is handled by
> ucspi-ssl with TLS patches.
Ok.
> We're currently using qpsmtpd which has a plugin that wraps qmail with
> perl based support for STARTTLS (using IO::Socket::SSL).
Wow. Isn't it easier to use sslserver to handle TLS encryption on a
defined port ?
However, this does not solve the problem of the client.
> Does Wietse Venema's STARTTLS vulnerability impact the STARTTLS
> enhancements used in ucspi-ssl, qpsmtpd or qmail-spamcontrol? The
> vulnerability is described here:
>
> http://www.securityfocus.com/bid/46767
>
> There is a fairly simple patch that fixes the TLS vulnerability and
> applies to netqmail-1.06-tls - I am wondering how the vulnerabilty might
> effect TLS functions in qpsmtpd and qmail-spamcontrol. The patch for TLS
> enhanced versions of vanilla qmail-1.03 is here:
>
> http://marc.info/?l=qmail-ldap&m=130564281418177&w=2
>
> There's a long list of spots to look for the vulnerability on the
> Security Focus site but neither qpsmtpd nor ucspi-ssl-tls are mentioned.
Yes, I know. The reason I did not include that into the current minor
version of Spamcontrol is -- it is not a vulnerability of qmail-smtpd.
However, a simple solution (not a 'fix') will be provided in Spamcontrol
2.7 (in beta).
Actually -- to my understanding -- there is some misunderstanding about
the problem. Wietse's description was unfortunately not clear enough. Let
me try to outline the problem (therefore, I cc'ed the qmail list).
Assume somebody tries to communicate with the server using SMTP and
STARTTLS:
C: <SYN>
S: 220 .... ESMTP
C: EHLO foo.bar
S: 250-mail.fehcom.net
250-PIPELINING
250-8BITMIME
250-SIZE 0
250-AUTH LOGIN PLAIN CRAM-MD5
250 STARTTLS
C: STARTTLS
S: 220 Ready to start TLS (#5.7.0)
Now, qmail-smtpd clears all the session state vars and essentially the
SMTP session starts from scratch.
This is the default; no vulnerability what so ever.
However, there MIGHT be another solution:
C: <SYN>
S: 220 .... ESMTP
C: EHLO foo.bar
S: 250-mail.fehcom.net
250-PIPELINING
250-8BITMIME
250-SIZE 0
250-AUTH LOGIN PLAIN CRAM-MD5
250 STARTTLS
C: AUTH PLAIN authinfo\0 MAIL FROM: <me>\0 RCPT TO: <you>\0 STARTTLS
This is the 'pipelining' case. Now, qmail-smtpd has already read -- before
the STARTTLS command was issued -- all other SMTP commands. They become
overwritten, as soon as the Client enters a new set of commands.
The problem Wietse describes is: In case the client *DOES NOT* provide a
new set of command, the old ones stay 'alive' and are not 'flushed'.
Considering the STARTTLS case, the information blasted out by the client
is of course unconditionally 'leaked'.
However, for the server (qmail-smtpd) it is completely irrelevant, whether
this information is provided *before* or *after* the STARTTLS is issued.
To be more precise:
a) Forgery of Mail From: and Rcpt To: is independent whether it happened
on a encrypted connection or not.
b) If the client starts with Authentication before STARTTLS has been
established, it is his own risk and without any consequences for the later
STARTTLS session, since
c) any Authentication information is dropped by qmail-smtpd once a
STARTTLS command is issued.
Thus, in short, there is no vulnerability in common sense.
The last behavior of client (Pipelining) would be very strange, though not
impossible in general.
However, there is certainly a flaw not flushing the input data buffer once
a STARTTLS command is issued by the client.
This behavior has been changed in Spamcontrol 2.7 (reorganizing the code).
---
I haven't analyzed any other email systems so far, but regarding (c) this
behavior is *required* by the RFCs, thus I believe are respected in
Postfix and Exim as well.
QMTP has no pipeling; the problem mentioned is SMTP related only.
Hope that helped.
regards.
--eh.
--
Dr. Erwin Hoffmann | FEHCom | http://www.fehcom.de
|
