openssh bugs - Aug 2013 - [Bug 2143] New: X11 forwarding for ipv4 is broken when ipv6 is disabled on the loopback interface

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

            Bug ID: 2143
           Summary: X11 forwarding for ipv4 is broken when ipv6 is
                    disabled on the loopback interface
           Product: Portable OpenSSH
           Version: 5.3p1
          Hardware: All
                OS: Linux
            Status: NEW
          Severity: minor
          Priority: P5
         Component: sshd
          Assignee: unassigned-bugs at mindrot.org
          Reporter: grier at gate.net

I haven't seen this exact bug reported, even on the current version.

If the ipv6 kernel module is loaded, and ipv6 is disabled on the
loopback interface, X forwarding (for ipv4, at least) is broken, unless
AddressFamily is set to "inet".

It seems that sshd will refuse to listen for X connections on ipv4 if
it can't open an ipv6 socket.  It listens for ssh connections on ipv4
either way, so this appears to be a bug.

Test by toggling /proc/sys/net/ipv6/conf/lo/disable_ipv6.

I could probably find the problem in the code, as I used to be a fairly
competent c programmer, but I just don't have the time.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

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

Loganaden Velvindron <loganaden at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |loganaden at gmail.com

--- Comment #1 from Loganaden Velvindron <loganaden at gmail.com> ---
(In reply to Grier Ellis from comment #0)
> I haven't seen this exact bug reported, even on the current version.
> 
> If the ipv6 kernel module is loaded, and ipv6 is disabled on the
> loopback interface, X forwarding (for ipv4, at least) is broken,
> unless AddressFamily is set to "inet".
> 
> It seems that sshd will refuse to listen for X connections on ipv4
> if it can't open an ipv6 socket.  It listens for ssh connections on
> ipv4 either way, so this appears to be a bug.
> 
> Test by toggling /proc/sys/net/ipv6/conf/lo/disable_ipv6.
I can confirm that the bug exists with -current as well.

I was able to reproduce it in our dual-stack
environment.
> 
> I could probably find the problem in the code, as I used to be a
> fairly competent c programmer, but I just don't have the time.
I'm looking at the code right now. This looks very interesting :-)

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

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

Andrey Borzenkov <arvidjaar at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |arvidjaar at gmail.com

--- Comment #2 from Andrey Borzenkov <arvidjaar at gmail.com> ---
Created attachment 2335
  --> https://bugzilla.mindrot.org/attachment.cgi?id=2335&action=edit
Suggested patch to fix X11 forwarding with IPv6 disabled

The problem is that getaddrinfo() without hints flags returns both IPv4
and IPv6 localhost addresses. There are two possible fixes:

1. add AI_ADDRCONFIG. This will work around this bug if IPv6 is
globally disabled, because no interface will have IPv6 address, but
still fails in corner case when some interface does have IPv6 but
localhost not.

2. Simply ignore this error. That is what generic forwarding does
anyway.

Attached patch implements #2. It tries to limit cases when we ignore
error to exactly IPv6 and address not available, but may be we can
simplify it and simply follow generic forwarding example.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

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

Kelley Cook <r.kelley.cook at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |r.kelley.cook at gmail.com

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

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

Darren Tucker <dtucker at zip.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dtucker at zip.com.au

--- Comment #3 from Darren Tucker <dtucker at zip.com.au> ---
Note that just ignoring the error will re-introduce
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1483

-- 
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=2143

--- Comment #4 from Andrey Borzenkov <arvidjaar at gmail.com> ---
(In reply to Darren Tucker from comment #3)
> Note that just ignoring the error will re-introduce
> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1483
Patch ignores one specific error only - EADDRNOTAVAIL. bind returns it
when requested address is not present on host. If listening address is
present, bind fails with EADDRINUSE and current behavior is not
changed.

-- 
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=2143

Petr Cerny [:hrosik] <pcerny at suse.cz> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pcerny at suse.cz

--- Comment #5 from Petr Cerny [:hrosik] <pcerny at suse.cz> ---
Created attachment 3044
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3044&action=edit
generally skip throwing away opened sockets on EADDRNOTAVAIL

I'm suppose the same could (in the future) happen for IPv4 (or other
protocols), it might be better not to limit it to IPv6.

Darren, do you have any concerns about this sort of limiting? AFAIU,
the only way CVE-2008-1483 could creep back in is that someone enables
disabled protocol and starts listening on the same port that is already
used (with the address family that was available at the moment the
connection was established).

-- 
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=2143

Jakub Jelen <jjelen at redhat.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jjelen at redhat.com

--- Comment #6 from Jakub Jelen <jjelen at redhat.com> ---
ping. Is there any update on this?

To my understanding and testing, the patch provided by Petr does NOT
expose the linked CVE, because the attack really depends on the
ignoring EADDRINUSE errno, which was the problem of implementation
before OpenSSH 5.0 but not of this patch.

I believe that it is not a priority for you, but on some systems with
disabled IPv6 this issue is pretty annoying. I can see in this bug that
there are at least three people who believe it is a bug and that this
patch is solving the problem without introducing any regression in
security.

So is there any chance to have this patch reviewed/accepted?

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

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

Andrey <ahippo at yandex.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ahippo at yandex.com

--- Comment #7 from Andrey <ahippo at yandex.com> ---
Still broken in 7.8p1 on Linux with IPv6 enabled in the kernel
(CONFIG_IPV6=y), but disabled (/proc/sys/net/ipv6/conf/lo/disable_ipv6)
at runtime.

Specifying "AddressFamily inet" fixes the problem.
Toggling "disable_ipv6" back also "fixes" the problem.

Setting "X11UseLocalhost no" also workarounds the problem in a more
dangerous way.

-- 
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=2143

Bill McGonigle <bill-bugzilla.mindrot.org at bfccomputing.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bill-bugzilla.mindrot.org at b
                   |                            |fccomputing.com

--- Comment #8 from Bill McGonigle <bill-bugzilla.mindrot.org at
bfccomputing.com> ---

I ran into this on a current Debian machine with ipv6.disable=1 on the
kernel command line (completely disables IPv6 at boot time).

When searching for:

  X11 forwarding request failed on channel 0

I came across many articles/stackexchanges offering advice for fixing
this, basically all saying to set:

  X11UseLocalhost no

Since everything works after setting it, it seems like "the fix" to
people who implement it.  Being naturally paranoid, I read the man
page, and, horrified, I went looking further.  I found:

  AddressFamily inet

which works properly for this machine, though it should be noted that
none of the other daemons running on it fail functionality with IPv6
disabled.

My concern is that by not addressing this problem, many users are
configuring their machines insecurely.  I see there are some security
concerns noted above if this isn't fixed correctly, but it needs to be
pointed out that not fixing it also has security concerns on an
ecosystem level.

Are there any concrete security objections to either of the proposed
patches?

SuSE appears to be carrying Andrev's patch.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

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

Alan D. Salewski <salewski at att.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |salewski at att.net

--- Comment #9 from Alan D. Salewski <salewski at att.net> ---
[Just want to note this experience and workaround for other Debian
users who
 might wander through here...]

I ran into this on a current Debian machine with the 'openssh-server'
package
version 1:8.2p1-4.

IPv6 is disabled on the host, but via a runtime sysctl.d/ file rather
than the
kernel command line option. The sysctl config file contains the
settings:

    net.ipv6.conf.all.disable_ipv6 = 1
    net.ipv6.conf.default.disable_ipv6 = 1

After cranking-up the sshd debug logging, I would see a ton of messages
like
the following in /var/log/auth.log when a client would connect with X11
forwarding requested ('-X'):

    Mar 31 06:22:42 myhostname sshd[3187]: debug2:
x11_create_display_inet: bind port 6011: Cannot assign requested
address
    Mar 31 06:22:42 myhostname sshd[3187]: debug3: sock_set_v6only: set
socket 9 IPV6_V6ONLY

Unlike the documented experience of others (above, and elsewhere on the
Net),
setting[0] 'AddressFamily inet' *did not* correct the problem for me.
However,
adding '-4' to the (otherwise empty) sshd startup options via the
'/etc/default/ssh' file did work.


[0] Actually, it was already set explicitly.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

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

Parke <parke.nexus at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://bugzilla.mindrot.or
                   |                            |g/show_bug.cgi?id=2636

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

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

Parke <parke.nexus at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |parke.nexus at gmail.com

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.