ietf-smtp
[Top] [All Lists]

Re: RSET command - possible security loophole

2011-06-01 16:11:52

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 cleared."

Our code RSET() code will clear the sender address and looking at Exim's smtp_reset(), it also clears the sender. Looking at Sendmail's CLEAR_STATE(cmd) macro which has a more complex readability but I see a dropenvelope() call and that seems to also clear envelope information.

This is what I believe what has always been implemented. I don't believe it is a "Mulligan" or "Redo" last state concept. If this is wrong, we need to correct it.

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.

So under that basis:

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

 C: MAIL FROM:<FOO>
 S: 530 User Not Authorized
 C: AUTH LOGIN

The following is invalid because it clears the MAIL FROM:

 C: RCPT TO:<USER(_at_)REMOTE-HOST(_dot_)COM>
 S: 530 Authentication required for relaying
 C: RSET
 S: 250 OK
 C: AUTH LOGIN

The following MAY BE invalid because it has started a mail transaction:

 C: RCPT TO:<USER(_at_)REMOTE-HOST(_dot_)COM>
 S: 530 Authentication required for relaying
 C: AUTH LOGIN

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

From a practical standpoint, it make sense because authentication is generally needed to be established before RCPT is issued simply to determine Local vs Relay authorization at the most fundamental level of SMTP operations.

However, this could be semantics based on private port 587 (SUBMIT) vs public port 25 operations.

In other words, for us, under SUBMIT, the MAIL FROM: must be an local account, under a public port 25, it is not enforced.

However, this was found to be a problem under public port 25 AUTH operations where the AUTH identity did not have to be associated with the MAIL FROM and the domain part was a locally hosted domain and the user-id was illegal. In other words, if there was bounces, the mail when back to LA-LA land.

   S: 220-example-host.com ESMTP Server
   C: EHLO client.example.com
   S: 250-example-host.com Hello client.example.com
   S: 250-AUTH LOGIN
   S: 250 AUTH=LOGIN
   C: AUTH LOGIN
   .....
   S: 235 2.7.0 Authentication successful
   C: MAIL FROM:<unknown-user(_at_)example-host(_dot_)com>
   S: 250 OK

For bounces, if not the return path is verified, the mail is goes to unknown return path. So what we do is check the user if the return path domain is local under all auth, non-auth sessions, like if it a 4409 logic.

--
Sincerely

Hector Santos
http://www.santronics.com