[Top] [All Lists]

Re: How aggressively to reject Pipelining errors?

2011-10-10 16:15:07

Julien ÉLIE 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"....

At the moment, I'm only performing this check after the STARTTLS
command. But that got me to wondering: would it be wise/unwise to check
after other commands, e.g., EHLO, DATA, or AUTH? RFC 2920 is silent on
the topic of what the server may do if the client violates the rules.

For what is worth, RFC 3977 (about NNTP) says:
   If the specific description of a command says it "MUST NOT be
   pipelined", that command MUST end any pipeline of commands.  That is,
   the client MUST NOT send any following command until it receives the
   CRLF at the end of the response from the command.  The server MAY
   ignore any data received after the command and before the CRLF at the
   end of the response is sent to the client.

I appreciate the thought, but I'm not sure the NNTP behavior has much relevance here. There's no provision in SMTP for ever throwing away any commands under any circumstances, and the strong historical precedent is to return an unambiguous error message any time the server doesn't understand the client.

Anyway, NNTP does not provide a generic response code to reject an unwanted command. Existing response codes have other meanings, and it does not seem great to re-use one of them, if not standardized.

Right, whereas SMTP does.

I think the differences here between NNTP and SMTP are so deep that the NNTP behavior doesn't really provide useful guidance for SMTP. But thanks, it's been too long since I looked at NNTP.