MBOX-Line: From dave at cridland.net  Tue Mar  8 15:08:07 2011
To: imap-protocol@u.washington.edu
From: Dave Cridland <dave@cridland.net>
Date: Fri Jun  8 12:34:45 2018
Subject: [Imap-protocol] Pipelined commands before completion of STARTTLS
In-Reply-To: <alpine.BSO.2.00.1103081341530.1958@morgaine.smi.sendmail.com>
References: <4D7690AE.8020003@andrew.cmu.edu>
	<alpine.BSO.2.00.1103081341530.1958@morgaine.smi.sendmail.com>
Message-ID: <20334.1299625687.587275@puncture>

On Tue Mar  8 21:58:18 2011, Philip Guenther wrote:
> On Tue, 8 Mar 2011, Ken Murchison wrote:
> > Pursuant to http://www.kb.cert.org/vuls/id/555316
> >
> > I was wondering what the proper server behavior should be if a  
> client
> > sends commands between STARTTLS and the server response.  RFC 3501
> > states that this is a client MUST NOT but doesn't discuss how the  
> server
> > should handle it.
> >
> > I can see two possibilities (maybe there are others):
> >
> > 1. Send a BAD response if a command is pipelined after STARTTLS.
> > Should BAD be sent in response to STARTTLS or the following  
> command?
> >
> > 2. Ignore the pipelined cleartext commands.
> 
> 3. immediately close the connection
> 
> 4. Treat data after the CRLF as data for the TLS handshake (i.e.,  
> to shave
>    an RTT off in the success case).  I seem to recall a proposal  
> for an
>    SMTP extension to indicate that the server would guarantee that
>    STARTTLS would succeed and that it could handle having the  
> client's
>    handshake message pipelined with the STARTTLS request.  (QTLS  
> was it?)

Yes, I like (4).

Does the panel think there's a similar vulnerability lurking in SASL  
negotiation? I'm thinking that for SASL negotiations carried out in  
the clear, intended to negotiate a security layer, there's a similar  
injection window on the final response sent by the client - ie, the  
attacker would inject into that packet after the response, in the  
hope that buffering would "execute" the command after the client has  
completed authenticating, conceptually "within" the security layer.

Dave.
-- 
Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

