On 07/10/2011 01:43, Carl S. Gutekunst wrote:
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.
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
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?