[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: RSET command - possible security loophole


Murray S. Kucherawy wrote:

-----Original Message-----
From: Ned Freed [mailto:ned.freed@xxxxxxxxxxx]
Sent: Tuesday, May 31, 2011 3:29 PM
To: Murray S. Kucherawy
Cc: ietf-smtp@xxxxxxx
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: 

   MAIL
   RCPT
   DATA
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

  T1   C: MAIL FROM:<FOO>
       ** CALL GREYLIST(IP) result: FAIL=450
  T2   S: 450 Greylist Rejected, try again later
  T3   C: MAIL FROM:<FOO>
       ** 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. 

--
Sincerely

Hector Santos
http://www.santronics.com