Message-ID: <47DE9FB0.5030801@alcatel-lucent.com>
Date:	Mon, 17 Mar 2008 11:43:28 -0500
From:	Nebojsa Miljanovic <neb@...atel-lucent.com>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
CC:	linux-kernel@...r.kernel.org,
	"Kittlitz, Edward (Ned)" <nkittlitz@...atel-lucent.com>,
	asweeney@...atel-lucent.com,
	"Polhemus, William (Bart)" <bpolhemus@...atel-lucent.com>
Subject: Re: SO_REUSEADDR not allowing server and client to use same port

Alan,
thanks. With that additional INFO, I was able to find detailed description of
this denial of service attack (attached below).
Just to clarify. Having this port re-use check prevents folks from launching
this attack as opposed to being victim of it?


2.4 Simultaneous Connections
Occasionally, it is possible that hosts XX and YY both wish to establish a
connection and both of them simultaneously initiate the handshake.  This is
called simultaneous connection establishment [RFC 793]. Both hosts XX and YY
send out SYN's to each other. When the SYN's are received, each receiver sends
out a SYN+ACK. Both hosts XX and YY must detect that the SYN and SYN+ACK
actually refer to the same connection. If both hosts XX and YY detect that the
SYN+ACK belongs to the SYN that was recently sent, they switch off the
connection establishment timer and move directly to the SYN_RECVD state. This
flaw could be used to stall a port on a host, using protocols such as FTP where
the server initiates a connection to the client.

As an example, consider (malicious) host XX which has started an (active) FTP
connection to a server YY. XX and YY are connected using the control-port (21 on
YY). YY initiates the connection establishment procedure to initiate data
transfer with XX.

YY sends a SYN to XX, and makes a transition to SYN_SENT state. YY also starts
the connection establishment timer.
XX receives the SYN, and responds with another SYN.
When YY receives the SYN, it assumes that this is a case of a simultaneous open
connection. So, it sends out SYN_ACK to XX, switches off the connection
establishment timer, and transitions to the state SYN_RCVD.
XX receives the SYN_ACK from YY, but does not send a reply.
Since YY is expecting a SYN_ACK in the SYN_RCVD state, and there is no timer, YY
gets stalled in SYN_RCVD state.
XX was able to create a denial-of-service attack.


Neb


On 3/15/2008 8:34 AM, Alan Cox wrote:
> On Thu, 13 Mar 2008 14:18:15 -0500
> Nebojsa Miljanovic <neb@...atel-lucent.com> wrote:
> 
> 
>>Alan,
>>I would appreciate it if you could elaborate on the security issue. Can you
>>describe the simultaneous connect scenario?
>>
>>We have a system we are migrating to Linux from Lynx. We have always had the
>>ability to re-use ports. We are wondering if this security issue is something we
>>should take seriously. Or, maybe it is not likely to be seen with our system
>>running well defined set of applications (i.e. not a PC where anybody could run
>>anything).
> 
> 
> See RFC 793. It is permissible for a connection to be created between two
> end points both making a connection (crossing SYN frames are both
> acked). Thus if you allow such reuse it is possible (although usually
> very very hard) to mount a timing based attack.
> 
> It's not a very practical attack in most scenarios so we block it out of
> correctness and concerns for completely robust and proper behaviour
> rather than because it is seen in the wild.
> 
> Alan


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists