[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 8 Nov 2017 10:34:35 -0600
From: Eric Blake <eblake@...hat.com>
To: oss-security@...ts.openwall.com,
Jonas 'Sortie' Termansen <sortie@...si.org>,
Florian Weimer <fweimer@...hat.com>, John Haxby <john.haxby@...cle.com>
Subject: Re: Race condition between UDP bind(2) and connect(2)
delivers wrong datagrams
On 11/08/2017 10:16 AM, Jonas 'Sortie' Termansen wrote:
>> 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.
>
> Absolutely, if the standard mdanated one behavior, and if all the
> implementations did something else and documented that they did so, it would
> be a bug in the standard that should be fixed.
>
> This issue is not that case because Darwin[1], DragonFly[2], FreeBSD[3],
> GNU/Hurd (though by importing Linux man pages), Linux[4], NetBSD[5], and
> OpenBSD[6] all document behavior compatible with POSIX[7].
It doesn't matter what the implementations document (if their
documentation is copying from POSIX), but what they actually DO.
> I see two internally consistent ways we could resolve this problem:
>
> 1) Implement the behavior described by POSIX by having connect(2) on an UDP
> socket filter the receive queue, and possibly updating the connect(2)
> documentation of every OS to be a little less ambiguous and say the same
> as POSIX. Software that relied on bind+connect not having a race
> condition will be secured by the kernel fix.
>
> 2) Declare the existing behavior desirable, add a caveats section to every
> connect(2) manual page describing this pitfall and the need to empty the
> receive queue after connect(2). File a POSIX bug and have the mandated
> behavior changed in the next POSIX Technical Corrigendum or next major
> update. We audit software on every operating system for this flaw and
> ensure they properly empty the receive queue.
At this point, I think you have argued pretty effectively that the
current POSIX wording does NOT describe existing practice, and therefore
that POSIX has a bug. It may be desirable to have implementations
follow the POSIX wording, but I think you are better off FIRST raising
this issue with the Austin Group
(http://austingroupbugs.net/main_page.php) to get an opinion on what the
POSIX folks think. Even if the POSIX folks declare that the current
wording is intentional and that all existing implementations need to be
fixed, it is better to involve them up front.
>
> My preference is 1) because I believe the receive queue filtering behavior
> to be more useful. It also automatically closes the race condition in any
> software that use bind+connect and doesn't empty the receive queue.
That may be your preference, but I think you should pursue the course of
filing a POSIX bug about the mismatch between documentation and existing
practice (ie, what you proposed for course 2), whether or not you get
any traction in implementing course 1 on a subset of the systems.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
Download attachment "signature.asc" of type "application/pgp-signature" (620 bytes)
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.
