Hi David,
I hope you had a pleasant journey in Paris last week. It was nice to meet you.
In 2005, I submitted a patch for 2.6.11 which we finally did not decide
on, it was about the ability to disable TCP simultaneous connection open.
For the last few years, we've been bothered several times by newbies
reading "TCP/IP for dummies" then trying to get a name by discovering
the ultimate vulnerability which will get a lot of press coverage. Of
course those attacks are often pointless or just proofs of concepts
with no application in real life, but it's nonetheless annoying to have
to deal with the issues, especially to explain to customers why they
shouldn't have to worry.
I would not be surprized that a next one will exploit TCP's ability to
perform simultaneous connections between two clients. It's very easy
to trigger, there's no SEQ to guess, just a port, and the effect is
simply a poor DoS on the service trying to connect outside. In other
times we would have found it very minor, but judging by the consideration
given to harder and less effective "attacks" these days, this trivial
one may finally get picked and annoy us again.
As a reminder (especially for those who are not aware of this feature),
it is possible with TCP to connect two clients together if both send
crossed SYNs, then SYN-ACKs, then ACKs. This implies that each side
accepts the sequence number of the other one without any ability to
check that it matches its SYN. So it's trivial for an attacker to
prevent one client from establishing a connection from a known port
to a known address/port by sending it a SYN to that port. The client
will then send a SYN-ACK and will not accept the expected server's
SYN-ACK because the SYN SEQ will be different. The server might also
send an RST on the client's SYN-ACK if it's not firewalled. The
connection will eventually timeout in a SYN-RECV state or simply be
aborted.
The theorical DoS effect on some predictable address/port destinations
is easy to understand. ...
