Created attachment 1343 [details] X11 bind(2) error handling. I was testing FreeBSD 6-STABLE with no IPv4 interfaces configured. I was unable to forward X11 in this configuration. The reason it failed was that IPv4 was the last address family returned by getaddrinfo(). The attached patch changes the error behaviour on bind(2) failures to be dependent on errno and not the position in the list returned by getaddrinfo(). Also logged w/ FreeBSD as bin/115960. Mark
Created attachment 1344 [details] X11 bind(2) error handling
The logic for X11 binding has changed as a result of http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1483 -- OpenSSH >5.0 will still fail in this case (getaddrinfo() returning both IPv4 and v6 addrs but bind not working for one of them), but it will fail /on purpose/. Given the problem that gave us CVE-2008-1483, I think OpenSSH refusing X11 forwarding is the only reasonable solution. IMO getaddrinfo() shouldn't return addresses that cannot be bound. A workaround for this is to explicitly set AddressFamily in sshd_config(5).
> The logic for X11 binding has changed as a result of > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1483 -- OpenSSH > >5.0 will still fail in this case (getaddrinfo() returning both IPv4 > and v6 addrs but bind not working for one of them), but it will fail > /on purpose/. There is a difference between EADDRINUSE and EADDRNOTAVAIL. One indicates that the <address,port> tuple is in use. The other indicates that the interface does not exist. > Given the problem that gave us CVE-2008-1483, I think OpenSSH refusing > X11 forwarding is the only reasonable solution. IMO getaddrinfo() > shouldn't return addresses that cannot be bound. A workaround for this > is to explicitly set AddressFamily in sshd_config(5). The case in CVE-2008-1483 is covered by moving to the next port on EADDRINUSE. The patch was to not fail for EADDRNOTAVAIL which is a completely different condition. All errors are not equal. Note the old code was wrong to continue on ai->ai_next being non NULL which was why I removed the examination of ai->ai_next when I reported this problem. I had already thought about other applications listening on one of the interfaces and not the other which is why I looked at the value of errno. Mark
Well, the case I had in mind was a machine that has an IPv6 address but not yet an IPv4 address (e.g. via rtsol and dhcp racing). sshd could end up binding the IPv6 socket but not an IPv4 one that could subsequently become valid.