Re: RSET command - possible security loophole

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 localhost.com ESMTP ready
   C: EHLO mail.example.com
   S: 250 localhost.com, Hello mail.example.com
   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 mail.example.com
   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:
RSET

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

MAIL FROM:

   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.

EHLO

   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.


--
Sincerely

Hector Santos
http://www.santronics.com