openssh bugs - Apr 2008 - [Bug 1457] New: X11 Forwarding doesn't work anymore on a solaris 10 host where ipv6 has not been enabled

https://bugzilla.mindrot.org/show_bug.cgi?id=1457

           Summary: X11 Forwarding doesn't work anymore on a solaris 10    
                    host where ipv6 has not been enabled                   
    Classification: Unclassified                                           
           Product: Portable OpenSSH                                       
           Version: 4.9p1                                                  
          Platform: All                                                    
        OS/Version: Solaris                                                
            Status: NEW                                                    
          Severity: major                                                  
          Priority: P2                                                     
         Component: sshd                                                   
        AssignedTo: bitbucket at mindrot.org                                  
        ReportedBy: yann at pleiades.fr.eu.org                                


Created an attachment (id=1481)
 --> (http://bugzilla.mindrot.org/attachment.cgi?id=1481)
Ignore a  EADDRNOTAVAIL error when binding to the X11 forwarding port

This bug happen with 5.0p1 (but this version was not available in the
version field of the bug report form).

The patch for CVE-2008-1483 applied in this release has a side effect
on Solaris (at least Solaris 10, I didn't test on other solaris
versions).

With this patch, openssh will do X forwarding on a port only if it
successfully binded to it on the inet4 and inet6 address (if the latter
was available).

The problem is that on Solaris 10, even if ipv6 was not enabled at
install time, the getaddrinfo will still return the ipv6 address in
addition to the ipv4 address.

As a result, when try to bind to port A, openssh will try to bind to
127.0.0.1:A and ::1:A, and the latter will always fail as there are not
ipv6-enabled localhost interface. 
So openssh will not be able to bind on any port and X Forwarding will
not work.

I don't know it it can be considered a solaris bug or openssh bug.


To fix this bug, I slightly modified the security fix patch so openssh
will ignore an error on an address if the errno is EADDRNOTAVAIL. 

This fixes the bug and still seems to avoid the X11 hijacking bug but I
am not sure it's the good solution.

One possible problem is if a sysadmin configures the inet6 loopback
interface after someone already did X forwarding.
That would leave a window for an attacker. He could then listen on the
6010 port on the inet6 interface to hijack X11 communication coming
from
apps which first try the ipv6 port.
That's not likely to happen often but still...

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=1457


Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added                       
----------------------------------------------------------------------------
                 CC|                            |djm at mindrot.org             




--- Comment #1 from Damien Miller <djm at mindrot.org>  2008-04-06
07:12:41 ---
I think this is a Solaris bug in the getaddrinfo implementation - there
is no reason for it to return addresses that will never bind.

You can work around this by specifying "AddressFamily inet" in your
sshd_config.

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=1457





--- Comment #2 from Yann Rouillard <yann at pleiades.fr.eu.org> 
2008-04-06 08:38:11 ---

Yes it's what I'm wondering and I am trying to see how other os behave.

BTW, while reading the getaddrinfo manpage, I found the following
option:

If the AI_ADDRCONFIG flag is specified, IPv4 addresses are returned
only if an IPv4 address is configured on the local system, and IPv6
addresses are returned only if an IPv6 address is configured on the
local system. For this case, the loopback address is not considered to
be as valid as a configured address. For example, when using the DNS, a
query for AAAA records should occur only if the node has at least one
IPv6 address configured (other than IPv6 loopback) and a query for A
records should occur only if the node has at least one IPv4 address
configured (other than the IPv4 loopback).

that could have been interesting.

However as an ipv6 loopback is not considered a valid interface, that
would still allow an attacker to hijack a X11 session in the case only
the loopback is ipv6 enabled and an application first try to talk to
the X11 forwarded port via tcp6.

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=1457





--- Comment #3 from Yann Rouillard <yann at pleiades.fr.eu.org> 
2008-04-06 09:51:53 ---
Made some test under Linux/Ubuntu and the same problem exists.

getaddrinfo also returns the ipv6 loopback address ::1 even if inet6 is
not configured on the interface.

But the thing is that it's not a standard setup under linux, usually,
either you have ipv6 enabled and ipv6 on all interfaces, or ipv6 is
disabled. To reproduce the bug, I had to load the ipv6 module and then
manually disable the inet6 loopback address.

You usually don't meet the solaris-like case where ipv6 is in fact
enabled but no interface is configured with ipv6 support.


So I suppose that theoretically, you should not assume that addresses
informations returned by getaddrinfo are valid ones, but I didn't yet
read POSIX to check.


BTW, I maintain the blastwave openssh package [1] and I would like to
apply the attached patch on the stable package. May I request your
opinion about it ?


[1] http://www.blastwave.org/

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=1457





--- Comment #4 from Damien Miller <djm at mindrot.org>  2008-04-06
12:15:38 ---
Well, I'd be wary of doing this - adding hacks to support broken
systems is what got us this bug to begin with :(

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=1457





--- Comment #5 from Yann Rouillard <yann at pleiades.fr.eu.org> 
2008-04-06 22:44:20 ---
Well, I don't want to break X11 forwarding on a lot of systems with a
stable update, so I just would like to know it the patch attached still
fixes properly the security hole without side-effects.

About this patch being a hack, it's true I have to make this
modification for a solaris-specific issue, but to not bind on
non-existing interface could be considered good behavior.

Anyway, if you're not interested in this issue, feel free to change it
to WONTFIX or INVALID.

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.