[Top] [All Lists]

Re: RSET command - possible security loophole

2011-05-31 20:56:55

Murray S. Kucherawy wrote:
-----Original Message-----
From: Ned Freed [mailto:ned(_dot_)freed(_at_)mrochek(_dot_)com]
Sent: Tuesday, May 31, 2011 3:29 PM
To: Murray S. Kucherawy
Cc: ietf-smtp(_at_)imc(_dot_)org
Subject: RE: RSET command - possible security loophole

Authentication (AUTH) and session security (STARTTLS) are the obvious examples,
but it is also very common for implementations to support proprietary
mechanisms to allow setting of various session attributes (including but not
limited to the real IP address of the client). Various sorts of proxies are the
usual use-case for this stuff.

Sorry, right, AUTH and STARTTLS of course. My point is that once you hit MAIL and thus begin message-specific operations rather than connection-specific ones, I can't think of any SMTP commands that go back and potentially alter session state in any obvious way that I can think of.

What am I missing?

Well, define "message-specific" because MAIL just gives you the envelope return path address and we already know that 5321.Mail may not be same as the 5322.From.

"message-specific" can just be the RFC5322 payload. Maybe you are pointing out that among the three commands:


for a given transaction, we already make persistent reply code decisions for the same MAIL and RCPT values repeated in all same session transactions before even getting to the DATA state.

Consider this timing sequence

       ** CALL GREYLIST(IP) result: FAIL=450
  T2   S: 450 Greylist Rejected, try again later
       ** CALL GREYLIST(IP) result: PASS
  T4   S: 250 OK

where T3 = T2 + 4 mins and the client waits there for 4 mins assuming that might be enough of a block time without the the 5 min standard IDLE timeout. But then again, he can issue a NOOP every minute to reset the server idle timeout counter, keep the session alive and wait 10 minutes!

I think its "valid" from the SMTP technical standpoint - he did wait enough to satisfy the block time. Normally, they disconnect and try later. But it would be sort of dumb to waste resources to wait.

So IMO, the issue is more about trying other transactions after DATA and how the server, in general, can be informed that new SMTP transactions would be disabled.


Hector Santos