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.
<csg>