On 07/10/2011 01:43, Carl S. Gutekunst wrote:
> In order to deal with the STARTTLS plaintext command injection
> vulnerability (CERT VU#555316), I added a check in my commands parser
> to error out on "illegal pipelining": if there is anything in the read
> I/O buffer when there shouldn't be, I return a 421 response and drop
> the connection.
Hang on, I'm worrying now - we don't do anything special about checking
the I/O buffer here, but I'm not sure how it could be abused.
If the client sends STARTTLS and other commands, then how would it get
through the STARTTLS negotiation, since it won't be able to pipeline the
negotiation data (not knowing what any challenges will be), so the
STARTTLS will fail, and the other pipelined commands will be processed
outside the TLS session.
Or, am I missing something?
It depends on your buffering and SSL/TLS implementation. If, say, your SSL/TLS
implementation only reads from a socket, when you turn it on it cannot see
data in application-layer buffers. So that data sits there until the SSL/TLS
negotiation is complete, and then gets consumed by the application and it
appears to have come in under the security layer.
Even then this probably doesn't amount to all that much in the case of SMTP,
but the combination of IMAP or POP and client certs can present a real