oss-sec mailing list archives
Re: Race condition between UDP bind(2) and connect(2) delivers wrong datagrams
From: Eric Blake <eblake () redhat com>
Date: Wed, 8 Nov 2017 10:34:35 -0600
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
Attachment:
signature.asc
Description: OpenPGP digital signature
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)