On Thu, May 04, 2000 at 01:16:41PM -0400, Joe Steele decided:

-------------snip------------------> 

> Why:  A bug?

> 

> I don't know that there actually is a "wrong" ACK # in a RST segment, except in one case.  The protocol requires that if the incoming segment (the one being reset) does not have an ACK # (e.g., it's a SYN segment), then the ACK # of the RST must be set equal to the incoming SEQ # plus the incoming segment length, thus effectively ACKing the incoming (SYN) segment.  Except for this case, the protocol is silent regarding the ACK # in the RST.  Therefore, while it might appear that your RST segment contained an ACK # "obviously meant for FE1", such behavior does not seem to violate the protocol.  Nonetheless, it does seem unusual, and the code that I've looked at behaves more logically by clearing the ACK # and the ACK bit. 

> 

> Probably of greater importance is the SEQ # of the RST segment.  If the incoming segment has an ACK #, then the SEQ # of the RST segment is set equal to the incoming ACK #.  This assures that the when the RST is received at the remote end, it will be found to fall within the receive window.  If this were not the case, the RST would be ignored.  (This protects against old RST segments floating around from prior connections.)

> 

> So the question is, does the RST contain a SEQ # "obviously meant for FE1"?

SEQ # was fine. And like I mentioned before, in an RST packet the ACK # is

trivial at best since the connection gets cut upon receipt.

> 

> > 2) Doesn't this present a small security problem since FE2 now knows information

> > about the current FE1 connection?

> > 

> While the behavour might not be desirable, I'm not coming up with any ideas of how it might be exploited. 

Well here's a thought...

You can't sniff the connection between FE1 and BoxA so if BoxA sends the *extra*

information to FE2, wouldn't you be that much closer to a session highjack? (I'm

still learning so flames > /dev/null)

Of note: the BoxA is an NT4.0 machine. It appears that when this box sends an

RST, it appends the last good ACK # irregardless of the connection id. Can

otheres verify this or explain why?


-- 
Randy Janinda
--
To unsubscribe: mail ">majordomo@ale.org with "unsubscribe ale" in message body.