[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: How aggressively to reject Pipelining errors?
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. My reasoning was that I don't want to allow the session to
continue if the client appears to be testing for that vulnerability.
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:
Except where stated otherwise, a client MAY use pipelining. That is,
it may send a command before receiving the response for the previous
command. The server MUST allow pipelining and MUST NOT throw away
any text received after a command. Irrespective of whether
pipelining is used, the server MUST process commands in the order
they are sent.
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.
STARTTLS, defined in RFC 4642 for NNTP, does not allow pipelining.
News servers can therefore just ignore the unwanted data.
The problem with returning an answer is that it can hinder a bug in the
client (which may never see the bug because it will for instance send
its command again, instead of exiting after a timeout) or cause
desynchronization issues in case the server does not answer as many
responses as the number of unwanted commands sent by 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.
« J'adore être pris en flagrant délire. » (Raymond Devos)