oss-sec mailing list archives
Re: Race condition between UDP bind(2) and connect(2) delivers wrong datagrams
From: John Haxby <john.haxby () oracle com>
Date: Tue, 7 Nov 2017 14:20:26 +0000
On 06/11/17 18:42, Florian Weimer wrote:
Even though it can be difficult to exploit this bug, it is a validation bug in the kernels. POSIX 2008 (2016 edition) says[1]: "For SOCK_DGRAM sockets, the peer address identifies where all datagrams are sent on subsequent send() functions, and limits the remote sender for subsequent recv() functions."Whatever the exact wording used is, the intent of POSIX is to describe the BSD sockets API behavior. If the API does something else, that's a POSIX bug.
It does say "subsequent" and says nothing about datagrams that might be received by the kernel before the connect(2). The Linux man page also has this to say:
Generally, connection-based protocol sockets may successfully connect() only once; connectionless protocol sockets may use connect() multiple times to change their association. Connectionless sockets may dissolve the association by connecting to an address with the sa_family member of sockaddr set to AF_UNSPEC (supported on Linux since kernel 2.2).
I know that that's not Posix, but it underlines the interesting question of what happens to packets that have already been received that have the "wrong" source address? You might hope that the kernel will just flush any datagrams that the application has picked up. What happens, though, if the program is working its way through datagrams that it has received or is receiving from the kernel? That's a rhetorical question -- it should, of course, discard packets it is (no longer) interested in. While there's plenty of scope for programs to get this wrong, I don't think the kernel is under any obligation to attempt to flush anything either from a standards point of view or from a real-world implementation point of view. jch
Current thread:
- Race condition between UDP bind(2) and connect(2) delivers wrong datagrams Jonas 'Sortie' Termansen (Nov 06)
- Re: Race condition between UDP bind(2) and connect(2) delivers wrong datagrams Florian Weimer (Nov 06)
- Re: Race condition between UDP bind(2) and connect(2) delivers wrong datagrams John Haxby (Nov 07)
- Re: Race condition between UDP bind(2) and connect(2) delivers wrong datagrams Jonas 'Sortie' Termansen (Nov 08)
- Re: Race condition between UDP bind(2) and connect(2) delivers wrong datagrams Eric Blake (Nov 08)
- Re: Race condition between UDP bind(2) and connect(2) delivers wrong datagrams Bob Friesenhahn (Nov 08)
- Re: Race condition between UDP bind(2) and connect(2) delivers wrong datagrams Florian Weimer (Nov 06)