[Top] [All Lists]

Re: RSET command - possible security loophole

2011-05-31 20:21:56

Murray S. Kucherawy wrote:

The place where "backwards" comes in is the place where I think
Hector has uncovered a problem, even though it is not the
problem his initial note was about.   I think that, as we are
checking extensions that  set data that needs to be carried from
one command to others, we should be checking to be sure that
action is either explicitly bound to either session or
transaction state or that new states are clearly defined.

Given that the model of SMTP in general involves some connection-specific
stuff (accept(), 220, EHLO, 250) followed by zero or more message-specific actions (MAIL, RCPT, DATA, RSET) and some things that have to do with neither (RSET, NOOP, HELP, VRFY, EXPN), I'm at a loss to understand how there's some blending of semantics here.

Other than mechanical errors and state to state flow allowance and restrictions, it is not SMTP that selects more "abstract" reply codes. These are based on local system implementation of policies. They define or direct what negative or positive reply codes are issued in order to drive the client/server state machine.

In general, each "mail transaction" (MAIL, RCPT, DATA) under the same section are viewed independent of each other. It could be a batching idea where multiple messages for the same target host are queued and you deal with them with one or more outbound attempts

But putting aside AUTH or IP based authentication for the moment, because I strongly believe most systems bypass SMTP level filtering or restrictions when we have an authenticated system, this is more about the unauthenticated, unknown, unsolicited messages coming in where these "filters" come into play, like SPF, DNSRBL and GreyListing. For our system, this overhead is skipped for authenticated sections.

So it comes down to something like this:

   S: 220 ESMTP ready
   C: EHLO
   S: 250, Hello
   C: MAIL FROM:<lucy(_at_)example(_dot_)com>
   S: 250 OK
   C: RCPT TO:<localuser(_at_)localhost(_dot_)com>
   S: 250 OK
   C: DATA
   S: 354 OK
   ** data transferred **
   S: 451 Greylisted policy rejection (transactions disabled)
   C: RSET
   S: 250 ok, but not really
   C: MAIL FROM:<ricky(_at_)example(_dot_)com>
   S: 450 Sessions Transactions Are Disabled
   C: EHLO
   S: 550 Sessions Transactions Are Disabled
   C: QUIT
   S: 221 closing connection <CLICK>

The question/issue/idea is whether there should be persistent "Global Session" condition that is now applied to the channel or current session for any new transaction attempts. So assuming this is practically reasonable, for the current commands that can begin the process of starting a new transaction:


   5321 does not allowed for negative reply codes for RSET so it has to
   be a 250.


   This might be debatable, but IMV, it should be a temporary rejection
   and/or follow the DATA reply code.   The main idea I think is we
don't want to tell the client his MAIL FROM address is not acceptable,
   unless it really is.


   5321 allows for a 550 and I think it would be appropriate here to
   use a permanent rejection code.

Are there properties of the session state, other than implementation-specific
ones, that might ever be altered by commands after EHLO? I can't think of any.

As noted above, SMTP does not make these reply code decisions for anyone. It only provide the mechanism for the state machine. It is always local policy based with implementations helping to operators to leverage how a state machine will flow.

Past EHLO, everything is either neutral or is a message-specific instruction of some kind. If that's the case, then declaring that RSET only ever resets message state seems like where the RFC should leave it.

In my code for RSET, and I took a look at Sendmail and Exim, they are just clearing, for the most part, MAIL, RCPT and DATA information. And they all use a single function that RSET, MAIL and EHLO calls.

So in reality, RSET/MAIL/EHLO would do the same thing. The main point here is whether new transactions MAY be disabled for the same session based on a condition occurring from an previous transaction, and really, I think its DATA because we already do it with MAIL and RCPT. Repeating the same MAIL and RCPT that was rejected once already is expected to be rejected again. So if they can't get pass MAIL or RCPT, they will never get to DATA anyway. So this is more above the final result with completing DATA.

Anyway, my opinion.


Hector Santos

<Prev in Thread] Current Thread [Next in Thread>