Re: [Fwd: STARTTLS vulnerabilty and qmail-spamcontrol ucspi-ssl qpsmtpd]

No takers? I do consider the bug fairly minor (it's not like a remote 
root or anything)... But still?

Matt Sergeant wrote:
> 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 <[email protected]>
> Subject:     STARTTLS vulnerabilty and qmail-spamcontrol ucspi-ssl 
> qpsmtpd
> Date:     Wed, 01 Jun 2011 15:03:51 -0400
> To:     [email protected], [email protected], Matt Sergeant 
> <[email protected]>
>
>
>
> Hi I'm a user of the qpsmtpd and qmail-spamcontrol ports on FreeBSD
> ([email protected] 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