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, DragonFly, FreeBSD, > GNU/Hurd (though by importing Linux man pages), Linux, NetBSD, and > OpenBSD all document behavior compatible with POSIX. 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.