ietf-smtp
[Top] [All Lists]

Re: How aggressively to reject Pipelining errors?

2011-10-08 06:11:58

Hi Carl,

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:

3.5.  Pipelining

   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.

--
Julien ÉLIE

« J'adore être pris en flagrant délire. » (Raymond Devos)