[Top] [All Lists]

Re: RSET command - possible security loophole

2011-06-01 16:48:42

--On Wednesday, June 01, 2011 16:57 -0400 Hector Santos
<hsantos(_at_)santronics(_dot_)com> wrote:

John C Klensin wrote:

Again, I believe that 5321 is quite clear on this.  If someone
believes otherwise, please identify the text that leads you to
believe that RCPT following after RSET with no intervening
MAIL command is valid so we can try to get it fixed.

Reading RSET it says "Any stored sender, recipients, and mail
data MUST be discarded, and all buffers and state tables


Either I'm confused or this is not nearly as complicated as
people are making it.

As far as when AUTH can appear, let's be clear that is a matter
of the specification for AUTH in RFC 4954 (or anywhere else one
can find an active specification for AUTH).  As far as 5321
_alone_ is concerned, it is simply an unrecognized command.
Unrecognized commands can be issued in any state at all and,
with a possible exception between connection opening and EHLO,
always get the same "unrecognized command" response (code 500,
see the last paragraph of Section 4.2.4 in RFC 5321).

I think we need to clarify "Mail Transaction" where it begins
and where it ends.  The spec says it starts with MAIL and I
believe it says it ends with DATA EOD.

Yeah, it does.  It also says that the effect of RSET or of a new
EHLO command is to end any "Mail Transactions" that happen to be
lying around.
So under that basis:

The following is valid because it hasn't started a mail

  S: 530 User Not Authorized

Yes, but only because of what 4984 says, not 5321.

The following is invalid because it clears the MAIL FROM:

  S: 530 Authentication required for relaying
  S: 250 OK

Assuming there was a MAIL command prior to the RCPT one,
otherwise it is invalid for other reasons (the response to RCPT
should be "503 Bad sequence of commands").  AUTH after RSET but
before MAIL is invalid only because 4894 says so.  5321 doesn't
have a position on the subject.

The following MAY BE invalid because it has started a mail

  S: 530 Authentication required for relaying

Unless your example is incomplete, it is invalid.  RCPT cannot
start a mail transaction.  The mail transaction must be started
by a MAIL command before RCPT appears.  The first paragraph of
Section 3.3 of RFC 5321 is, I believe, exceptionally clear.  If
there was a mail transaction open (i.e., the MAIL command was
successfully issued but not shown in your example), whether the
above is valid or not is a matter for 4954 and...

and according to 2554/4954, it is not permitted to issue the
AUTH once a mail transaction has started.

If that is the case (I haven't reviewed 4954 today), then it is
invalid because either there is a mail transaction open, making
AUTH invalid, or there is no mail transaction open, making RCTP
invalid for more fundamental reasons than the authentication
requirement.   I wouldn't claim returning 530 instead of 503 is
definitely a bug, but it is at least bad taste.