Re: [PATCH] fix small DoS on connect() (was Re: BUG: Unusual TCP Connect() results.)

On Sun, Jun 12, 2005 at 11:13:23PM +1000, Herbert Xu wrote:

On Sun, Jun 12, 2005 at 02:32:53PM +0200, Willy Tarreau wrote:

quoted

but it's not the case (although the naming is not clear). So if the remote
end was the one which sent the SYN-ACK, it will clear its session. If it has
been spoofed, it will ignore the RST because in turn, the SEQ will not be
within its window.

This is what should happen:

1) client A sends SYN to server B.
2) attcker C sends spoofed SYN-ACK to client A purporting to be server B.
3) client A sends RST to server B.

Agreed till here.

The RST packet is sent by client A using its sequence numbers.  Therefore
it will pass the sequence number check on server B.

4) server B resets the connection.

No, precisely the RST sent by A will take its SEQ from C's ACK number.
This is why B will *not* reset the connection (again, tested) if C's ACK
was not within B's window.

Cheers,
Willy

* Willy Tarreau [off-list ref] 2005-06-12 15:36

quoted

The RST packet is sent by client A using its sequence numbers.  Therefore
it will pass the sequence number check on server B.

4) server B resets the connection.

No, precisely the RST sent by A will take its SEQ from C's ACK number.
This is why B will *not* reset the connection (again, tested) if C's ACK
was not within B's window.

Absolutely but it relies on the other stack being correctly implemented.
The attack would work perfectly fine if there wasn't the rule that a RST
must not be sent in response to another RST. The attack has been
successful and still is because some firewalls are configured to send
RSTs without respecting this rule.

I like your patch and the idea behind it, it can successfully defeat the
most simple method of preventing connections being established.