[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <bf387118-b094-17b1-a023-39af87742479@oracle.com>
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[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
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.
