SO_REUSEADDR with UDP (again)
in [Kernel]
|
Prev: DMA Engine API usage
Next: xtables: make XT_ALIGN() usable in exported headers by exporting __ALIGN_KERNEL()
From: Michal Svoboda on 13 Apr 2010 05:10 Hello, I found SO_REUSEADDR on UDP sockets to behave somewhat nasty. If you create a UDP socket with that flag and bind it to a port, then anyone doing the same later will "steal" your packets, ie. 1. process A binds to port 12345 with SO_REUSEADDR, packets to that port go to process A 2. process B binds to port 12345 with SO_REUSEADDR, packets to that port now go to process B 3. A dies, fires up again, packets go back to A 4. A dies, does not fire up, packets go to B, as if they were stacked And this works even if A and B are owned by different users, thus anyone can "steal" packets from anyone as long as they use SO_REUSEADDR. However, in most programs that's the default. Furthermore, one can lock-out a particular source from being "stolen" by using connect() to that source, ie. 1. process A binds to port 12345 with SO_REUSEADDR, gets the packets 2. B does the same, gets the packets, but also connect()s to the source of the packets 3. A can now restart or try to bind again, but does not get the packets (from that source) (I haven't tested the case if A also issues a connect() even if it does not receive packets.) All of this seems confusing to me, and the fact that users can steal packets from each other seems like a mild security risk. I've found some discussions about this from circa 2002, but the above cases were not mentioned. So - a problem or not? Michal Svoboda
From: David Miller on 13 Apr 2010 05:20
The networking developers generally do not listen to linux-kernel To reach them submit your posting with netdev(a)vger.kernel.org on the CC: list. Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |