Date: Tue, 7 Nov 2017 14:20:26 +0000 From: John Haxby <john.haxby@...cle.com> To: oss-security@...ts.openwall.com Subject: Re: Race condition between UDP bind(2) and connect(2) delivers wrong datagrams 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: >> >> "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
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.