I don't see how it's a security flaw of any kind.  I'm not entirely 
certain it's actually a bug, except that it's a minor violation of an RFC.

For those who don't feel like reading through the long writeup from 
postfix-users, the executive summary follows: It's possible to send 
multiple SMTP commands in a single TCP/IP packet, which spamdyke (or any 
server) will read all at once.  If the packet contains the "STARTTLS" 
command and some other commands, a buggy server will start TLS *and* 
interpret the other commands immediately afterward.  The buggy server 
will assume the other commands were issued after encryption was 
established, when they were actually sent unencrypted.

This could be a security issue if someone (a man-in-the-middle) were 
able to intercept the "STARTTLS" command and append some malicious 
commands to the same packet.  But no such malicious commands exist.  
spamdyke doesn't change any of its behavior just because TLS has started 
-- all of the filters in effect before TLS are still in effect after 
TLS.  Even if the attacker appended a sender, a recipient and a message, 
spamdyke would still reject it (if appropriate).  The only way I can see 
this might be exploited would be if the client authenticated *before* 
starting TLS (I've never seen a mail client that does this).  However in 
that case, the attacker could inject SMTP commands at any time, even if 
TLS is never used.  Am I missing something?

The reason I'm not sure this is a bug is that I can easily imagine some 
lazy mail clients sending several commands after "STARTTLS" in the same 
packet, assuming TLS would start successfully (or not caring if it 
didn't).  Throwing away the extra content will delete those commands and 
break those clients.

That being said, I think this should probably fixed -- it's more likely 
to indicate a bug in the client than desired behavior.  Shouldn't be too 
difficult in spamdyke.  Not sure about the qmail patches though -- I've 
never looked at them.  I'll also look at making spamdyke correct this 
behavior for unfixed qmail installations when TLS is just being passed 
through.

-- Sam Clippinger

On 3/8/11 12:15 PM, Eric Shubert wrote:
> This came across on the Dovecot list recently:
> http://marc.info/?l=postfix-users&m=129952854117623&w=2
>
> Eric B on the QMT list has done some testing, and it appears that both
> spamdyke and qmail-smtpd presently contain this flaw.
>
> Sam, will you have a look into this? The link explains the situation in
> good detail. While I wouldn't call this a severe bug, it is a real
> vulnerability none the less.
>
> Also, I'm not familiar at all with the qmail-smtpd code. QMT presently
> uses these TLS patches:
> http://erresea.arda.homeunix.net/store/qmail/
> http://inoa.net/qmail-tls/
> Do you have any words of wisdom regarding these patches? I hope that
> someone in the QMT community (myself, if nobody else steps up) can get
> this code fixed as well.
>
> Thanks Sam, for all you do.
>
>    
_______________________________________________
spamdyke-users mailing list
[email protected]
http://www.spamdyke.org/mailman/listinfo/spamdyke-users

Reply via email to