How aggressively to reject Pipelining errors?
2011-10-06 19:54:49
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.
<csg>
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- How aggressively to reject Pipelining errors?,
Carl S. Gutekunst <=
|
|
|