I'm forwarding this to the list since I didn't get a response from Ask...
The problem here is when someone sends the following packet:
STARTTLS\nSOME_COMMAND\n
The SOME_COMMAND bit gets cached internally (in PollServer/async that's
in $qp->{line}, but in the other implementations I have no idea what
happens) and then because SSL upgrading happens in external libraries,
they don't see these bits of data, so what then happens is ssl gets
upgraded, but then SOME_COMMAND gets executed after SSL has been negotiated.
I'm pretty sure this is enough to fix it for async:
diff --git a/plugins/tls b/plugins/tls
index 37fbc9a..f850d2c 100644
--- a/plugins/tls
+++ b/plugins/tls
@@ -275,6 +275,7 @@ sub upgrade_socket {
my UpgradeClientSSL $self = shift;
unless ( $self->{_ssl_started} ) {
+ $self->{_stashed_qp}->clear_data();
IO::Socket::SSL->start_SSL(
$self->{_stashed_qp}->{sock}, {
SSL_use_cert => 1,
I've submitted a pull request for that.
But for the non-async scenario I think it's a lot more complex because
the caching would be done at the C-level, so a fix more like the fix
(posted below) for postfix is required (switch to non-blocking, get
whatever data is remaining, flush it, switch back off non-blocking).
-------- Original Message --------
From: Graham Todd <gt...@iciti.ca>
Subject: STARTTLS vulnerabilty and qmail-spamcontrol ucspi-ssl qpsmtpd
Date: Wed, 01 Jun 2011 15:03:51 -0400
To: m...@fehcom.de, ga...@freebsd.org, Matt Sergeant <m...@sergeant.org>
Hi I'm a user of the qpsmtpd and qmail-spamcontrol ports on FreeBSD
(ga...@freebsd.org 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. We're currently using qpsmtpd which has a
plugin that wraps qmail with perl based support for STARTTLS (using
IO::Socket::SSL).
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.
Cheers,
gtodd
