thr3ads.net - openssh unix dev - 5.2: Solaris 10 x86 x-11 forwarding fails, assign requested address [May 2010]

If this information is useful, please help other people find it:
Share via:

Seth Ellsworth

2010-May-24 20:46 UTC

5.2: Solaris 10 x86 x-11 forwarding fails, assign requested address

This is on Solaris 10 x86, do not see this behavior on Solaris 10 sparc. Seen on
multiple machines.

Sshd debug:
debug1: server_input_channel_open: ctype session rchan 256 win 16384 max 16384
debug1: input_session_request
debug1: channel 0: new [server-session]
debug2: session_new: allocate (allocated 0 max 10)
debug3: session_unused: session id 0 unused
debug1: session_new: session 0
debug1: session_open: channel 0
debug1: session_open: session 0: link with channel 0
debug1: server_input_channel_open: confirm session
debug1: server_input_channel_req: channel 0 request x11-req reply 1
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req x11-req
debug2: bind port 6010: Cannot assign requested address
debug2: bind port 6011: Cannot assign requested address
debug2: bind port 6012: Cannot assign requested address
...
debug2: bind port 6997: Cannot assign requested address
debug2: bind port 6998: Cannot assign requested address
debug2: bind port 6999: Cannot assign requested address
Failed to allocate internet-domain X11 display socket.
debug1: x11_create_display_inet failed.


In a previous version, 4.7, this worked, and looked like:
debug1: server_input_channel_req: channel 0 request x11-req reply 1
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req x11-req
debug2: bind port 6010: Cannot assign requested address
debug2: fd 7 setting O_NONBLOCK
debug3: fd 7 is O_NONBLOCK
debug1: channel 1: new [X11 inet listener]
debug1: server_input_channel_req: channel 0 request exec reply 1


Looking at differences between the 4.7 and 5.2 ( 5.5 is the same in this regards
), the difference seems to be in:
channels.c
Function: x11_create_display_inet
Line:2908: ( 4.7p1 code )
                if (ai->ai_next)
                    continue;
That's right after the bind fails.

If I follow the behavior, the first ai from getaddrinfo is an IPV6 address
that's not valid. Errno is EADDRNOTAVAIL.

Now in 4.7 the continue would make it just try the next ai.
In 5.2 that continue isn't there, so instead it breaks and tries the next
port number, on the same ai, which fails all the way until MAX_DISPLAYS is
reached.

For this situation I want to put back the if/continue, but I assume it was
removed for a reason, and wanted to find out if anyone here knew.



Ok, found the cvsweb, and located this:
Revision 1.272.2.1:
download<http://www.openbsd.org/cgi-bin/cvsweb/%7Echeckout%7E/src/usr.bin/ssh/channels.c?rev=1.272.2.1;content-type=text%2Fplain>
- view:
text<http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/channels.c?rev=1.272.2.1;content-type=text%2Fplain>,
markup<http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/channels.c?rev=1.272.2.1;content-type=text%2Fx-cvsweb-markup>,
annotated<http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/channels.c?annotate=1.272.2.1>
- select for
diffs<http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/channels.c?r1=1.272.2.1#rev1.272.2.1>
Thu Apr 3 03:42:02 2008 UTC (2 years, 1 month ago) by brad
Branches:
OPENBSD_4_3<http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/channels.c?only_with_tag=OPENBSD_4_3>
Diff to: previous 1.272:
preferred<http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/channels.c.diff?r1=1.272;r2=1.272.2.1>,
coloured<http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/channels.c.diff?r1=1.272;r2=1.272.2.1;f=h>;
next MAIN 1.273:
preferred<http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/channels.c.diff?r1=1.273;r2=1.272.2.1>,
coloured<http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/channels.c.diff?r1=1.273;r2=1.272.2.1;f=h>
Changes since revision 1.272: +1 -4 lines

avoid possible hijacking of x11-forwarded connections (back out 1.183)

CVE-2008-1483; ok djm@


Ok, this was removed to address an attack type. So, how do I fix this so I keep
the needed behavior but don't introduce the vulnerability?

The root of the problem seems to be getting an invalid IPV6 addrinfo, and that
failure means it doesn't try any other addrofinfo's, instead looping on
port's, which all fail, because the addrinfo always fails.

How about adding it back under certain circumstances:
sellswor at sethe:~/tmp/2/openssh-5.5p1> diff -u channels.c channels.c.orig
--- channels.c  2010-05-24 14:44:15.000000000 -0600
+++ channels.c.orig     2010-05-24 14:43:32.000000000 -0600
@@ -3271,13 +3271,9 @@
                        if (x11_use_localhost)
                                channel_set_reuseaddr(sock);
                        if (bind(sock, ai->ai_addr, ai->ai_addrlen) <
0) {
-                int loc_errno = errno;
                                debug2("bind port %d: %.100s", port,
strerror(errno));
                                close(sock);

-                if( loc_errno == EADDRNOTAVAIL && ai->ai_next )
-                    continue;
-
                                for (n = 0; n < num_socks; n++) {
                                        close(socks[n]);
                                }
You have new mail in /var/spool/mail/sellswor
sellswor at sethe:~/tmp/2/openssh-5.5p1>

Thoughts?

Am I approaching this wrong, and this shows a mis-configured machine? ( happens
on multiple machines, all default setups connected to IPV4 networks ).
---
Seth Ellsworth
Vintela Development
The people and products of Vintela are now a part of Quest Software.
Read the press
release<dhtmled5://exchweb/bin/redir.asp?URL=http://www.quest.com/news/show.asp?ContentId=1826%26ContentTypeId=2%26site=>
to learn more.

Douglas E. Engert

2010-May-24 21:41 UTC

head link

5.2: Solaris 10 x86 x-11 forwarding fails, assign requested address

Seth Ellsworth wrote:> This is on Solaris 10 x86, do not see this behavior on Solaris 10 sparc.
Seen on multiple machines.
> 
> Sshd debug:
> debug1: server_input_channel_open: ctype session rchan 256 win 16384 max
16384
> debug1: input_session_request
> debug1: channel 0: new [server-session]
> debug2: session_new: allocate (allocated 0 max 10)
> debug3: session_unused: session id 0 unused
> debug1: session_new: session 0
> debug1: session_open: channel 0
> debug1: session_open: session 0: link with channel 0
> debug1: server_input_channel_open: confirm session
> debug1: server_input_channel_req: channel 0 request x11-req reply 1
> debug1: session_by_channel: session 0 channel 0
> debug1: session_input_channel_req: session 0 req x11-req
> debug2: bind port 6010: Cannot assign requested address
> debug2: bind port 6011: Cannot assign requested address
> debug2: bind port 6012: Cannot assign requested address
> ...
> debug2: bind port 6997: Cannot assign requested address
> debug2: bind port 6998: Cannot assign requested address
> debug2: bind port 6999: Cannot assign requested address
> Failed to allocate internet-domain X11 display socket.
> debug1: x11_create_display_inet failed.
> 
> 
> In a previous version, 4.7, this worked, and looked like:
> debug1: server_input_channel_req: channel 0 request x11-req reply 1
> debug1: session_by_channel: session 0 channel 0
> debug1: session_input_channel_req: session 0 req x11-req
> debug2: bind port 6010: Cannot assign requested address
> debug2: fd 7 setting O_NONBLOCK
> debug3: fd 7 is O_NONBLOCK
> debug1: channel 1: new [X11 inet listener]
> debug1: server_input_channel_req: channel 0 request exec reply 1
> 
> 
> Looking at differences between the 4.7 and 5.2 ( 5.5 is the same in this
regards ), the difference seems to be in:
> channels.c
> Function: x11_create_display_inet
> Line:2908: ( 4.7p1 code )
>                 if (ai->ai_next)
>                     continue;
> That's right after the bind fails.
> 
> If I follow the behavior, the first ai from getaddrinfo is an IPV6 address
that's not valid. Errno is EADDRNOTAVAIL.
> 
> Now in 4.7 the continue would make it just try the next ai.
> In 5.2 that continue isn't there, so instead it breaks and tries the
next port number, on the same ai, which fails all the way until MAX_DISPLAYS is
reached.
> 
> For this situation I want to put back the if/continue, but I assume it was
removed for a reason, and wanted to find out if anyone here knew.
> 
> 
> 
> Ok, found the cvsweb, and located this:
> Revision 1.272.2.1:
download<http://www.openbsd.org/cgi-bin/cvsweb/%7Echeckout%7E/src/usr.bin/ssh/channels.c?rev=1.272.2.1;content-type=text%2Fplain>
- view:
text<http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/channels.c?rev=1.272.2.1;content-type=text%2Fplain>,
markup<http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/channels.c?rev=1.272.2.1;content-type=text%2Fx-cvsweb-markup>,
annotated<http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/channels.c?annotate=1.272.2.1>
- select for
diffs<http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/channels.c?r1=1.272.2.1#rev1.272.2.1>
> Thu Apr 3 03:42:02 2008 UTC (2 years, 1 month ago) by brad
> Branches:
OPENBSD_4_3<http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/channels.c?only_with_tag=OPENBSD_4_3>
> Diff to: previous 1.272:
preferred<http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/channels.c.diff?r1=1.272;r2=1.272.2.1>,
coloured<http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/channels.c.diff?r1=1.272;r2=1.272.2.1;f=h>;
next MAIN 1.273:
preferred<http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/channels.c.diff?r1=1.273;r2=1.272.2.1>,
coloured<http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/channels.c.diff?r1=1.273;r2=1.272.2.1;f=h>
> Changes since revision 1.272: +1 -4 lines
> 
> avoid possible hijacking of x11-forwarded connections (back out 1.183)
> 
> CVE-2008-1483; ok djm@
> 
> 
> Ok, this was removed to address an attack type. So, how do I fix this so I
keep the needed behavior but don't introduce the vulnerability?
> 
> The root of the problem seems to be getting an invalid IPV6 addrinfo, and
that failure means it doesn't try any other addrofinfo's, instead
looping on port's, which all fail, because the addrinfo always fails.
> 
> How about adding it back under certain circumstances:
> sellswor at sethe:~/tmp/2/openssh-5.5p1> diff -u channels.c
channels.c.orig
> --- channels.c  2010-05-24 14:44:15.000000000 -0600
> +++ channels.c.orig     2010-05-24 14:43:32.000000000 -0600
> @@ -3271,13 +3271,9 @@
>                         if (x11_use_localhost)
>                                 channel_set_reuseaddr(sock);
>                         if (bind(sock, ai->ai_addr, ai->ai_addrlen)
< 0) {
> -                int loc_errno = errno;
>                                 debug2("bind port %d: %.100s",
port, strerror(errno));
>                                 close(sock);
> 
> -                if( loc_errno == EADDRNOTAVAIL && ai->ai_next )
> -                    continue;
> -
>                                 for (n = 0; n < num_socks; n++) {
>                                         close(socks[n]);
>                                 }
> You have new mail in /var/spool/mail/sellswor
> sellswor at sethe:~/tmp/2/openssh-5.5p1>
> 
> Thoughts?
Sounds like it is related to IPv6  Google for: ssh bind X11 ipv6
and also see: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=327443
> 
> Am I approaching this wrong, and this shows a mis-configured machine? (
happens on multiple machines, all default setups connected to IPV4 networks ).
> ---
> Seth Ellsworth
> Vintela Development
> The people and products of Vintela are now a part of Quest Software.
> Read the press
release<dhtmled5://exchweb/bin/redir.asp?URL=http://www.quest.com/news/show.asp?ContentId=1826%26ContentTypeId=2%26site=>
to learn more.
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
> 
> 
-- 

  Douglas E. Engert  <DEEngert at anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444

Peter Stuge

2010-May-24 22:55 UTC

head link

5.2: Solaris 10 x86 x-11 forwarding fails, assign requested address

Seth Ellsworth wrote:> So, how do I fix this so I keep the needed behavior but don't
> introduce the vulnerability?
..> Am I approaching this wrong, and this shows a mis-configured
> machine? ( happens on multiple machines, all default setups
> connected to IPV4 networks ).
If they are only connected with v4 but your kernel has v6 support
enabled then try running sshd -4 to make sshd only use v4.


//Peter

Seth Ellsworth

2010-May-24 23:41 UTC

head link

5.2: Solaris 10 x86 x-11 forwarding fails, assign requested address

Thanks, I'll see if those lead to anything on this.

---

Seth Ellsworth

Vintela Development

The people and products of Vintela are now a part of Quest Software.

Read the press release to learn more.


-----Original Message-----
From: Douglas E. Engert [mailto:deengert at anl.gov]
Sent: Monday, May 24, 2010 3:42 PM
To: Seth Ellsworth
Cc: openssh-unix-dev at mindrot.org
Subject: Re: 5.2: Solaris 10 x86 x-11 forwarding fails, assign requested address



Seth Ellsworth wrote:> This is on Solaris 10 x86, do not see this behavior on Solaris 10 sparc.
Seen on multiple machines.
>
> Sshd debug:
> debug1: server_input_channel_open: ctype session rchan 256 win 16384 max
16384
> debug1: input_session_request
> debug1: channel 0: new [server-session]
> debug2: session_new: allocate (allocated 0 max 10)
> debug3: session_unused: session id 0 unused
> debug1: session_new: session 0
> debug1: session_open: channel 0
> debug1: session_open: session 0: link with channel 0
> debug1: server_input_channel_open: confirm session
> debug1: server_input_channel_req: channel 0 request x11-req reply 1
> debug1: session_by_channel: session 0 channel 0
> debug1: session_input_channel_req: session 0 req x11-req
> debug2: bind port 6010: Cannot assign requested address
> debug2: bind port 6011: Cannot assign requested address
> debug2: bind port 6012: Cannot assign requested address
> ...
> debug2: bind port 6997: Cannot assign requested address
> debug2: bind port 6998: Cannot assign requested address
> debug2: bind port 6999: Cannot assign requested address
> Failed to allocate internet-domain X11 display socket.
> debug1: x11_create_display_inet failed.
>
>
> In a previous version, 4.7, this worked, and looked like:
> debug1: server_input_channel_req: channel 0 request x11-req reply 1
> debug1: session_by_channel: session 0 channel 0
> debug1: session_input_channel_req: session 0 req x11-req
> debug2: bind port 6010: Cannot assign requested address
> debug2: fd 7 setting O_NONBLOCK
> debug3: fd 7 is O_NONBLOCK
> debug1: channel 1: new [X11 inet listener]
> debug1: server_input_channel_req: channel 0 request exec reply 1
>
>
> Looking at differences between the 4.7 and 5.2 ( 5.5 is the same in this
regards ), the difference seems to be in:
> channels.c
> Function: x11_create_display_inet
> Line:2908: ( 4.7p1 code )
>                 if (ai->ai_next)
>                     continue;
> That's right after the bind fails.
>
> If I follow the behavior, the first ai from getaddrinfo is an IPV6 address
that's not valid. Errno is EADDRNOTAVAIL.
>
> Now in 4.7 the continue would make it just try the next ai.
> In 5.2 that continue isn't there, so instead it breaks and tries the
next port number, on the same ai, which fails all the way until MAX_DISPLAYS is
reached.
>
> For this situation I want to put back the if/continue, but I assume it was
removed for a reason, and wanted to find out if anyone here knew.
>
>
>
> Ok, found the cvsweb, and located this:
> Revision 1.272.2.1:
download<http://www.openbsd.org/cgi-bin/cvsweb/%7Echeckout%7E/src/usr.bin/ssh/channels.c?rev=1.272.2.1;content-type=text%2Fplain>
- view:
text<http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/channels.c?rev=1.272.2.1;content-type=text%2Fplain>,
markup<http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/channels.c?rev=1.272.2.1;content-type=text%2Fx-cvsweb-markup>,
annotated<http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/channels.c?annotate=1.272.2.1>
- select for
diffs<http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/channels.c?r1=1.272.2.1#rev1.272.2.1>
> Thu Apr 3 03:42:02 2008 UTC (2 years, 1 month ago) by brad
> Branches:
OPENBSD_4_3<http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/channels.c?only_with_tag=OPENBSD_4_3>
> Diff to: previous 1.272:
preferred<http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/channels.c.diff?r1=1.272;r2=1.272.2.1>,
coloured<http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/channels.c.diff?r1=1.272;r2=1.272.2.1;f=h>;
next MAIN 1.273:
preferred<http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/channels.c.diff?r1=1.273;r2=1.272.2.1>,
coloured<http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/channels.c.diff?r1=1.273;r2=1.272.2.1;f=h>
> Changes since revision 1.272: +1 -4 lines
>
> avoid possible hijacking of x11-forwarded connections (back out 1.183)
>
> CVE-2008-1483; ok djm@
>
>
> Ok, this was removed to address an attack type. So, how do I fix this so I
keep the needed behavior but don't introduce the vulnerability?
>
> The root of the problem seems to be getting an invalid IPV6 addrinfo, and
that failure means it doesn't try any other addrofinfo's, instead
looping on port's, which all fail, because the addrinfo always fails.
>
> How about adding it back under certain circumstances:
> sellswor at sethe:~/tmp/2/openssh-5.5p1> diff -u channels.c
channels.c.orig
> --- channels.c  2010-05-24 14:44:15.000000000 -0600
> +++ channels.c.orig     2010-05-24 14:43:32.000000000 -0600
> @@ -3271,13 +3271,9 @@
>                         if (x11_use_localhost)
>                                 channel_set_reuseaddr(sock);
>                         if (bind(sock, ai->ai_addr, ai->ai_addrlen)
< 0) {
> -                int loc_errno = errno;
>                                 debug2("bind port %d: %.100s",
port, strerror(errno));
>                                 close(sock);
>
> -                if( loc_errno == EADDRNOTAVAIL && ai->ai_next )
> -                    continue;
> -
>                                 for (n = 0; n < num_socks; n++) {
>                                         close(socks[n]);
>                                 }
> You have new mail in /var/spool/mail/sellswor
> sellswor at sethe:~/tmp/2/openssh-5.5p1>
>
> Thoughts?
Sounds like it is related to IPv6  Google for: ssh bind X11 ipv6
and also see: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=327443
>
> Am I approaching this wrong, and this shows a mis-configured machine? (
happens on multiple machines, all default setups connected to IPV4 networks ).
> ---
> Seth Ellsworth
> Vintela Development
> The people and products of Vintela are now a part of Quest Software.
> Read the press
release<dhtmled5://exchweb/bin/redir.asp?URL=http://www.quest.com/news/show.asp?ContentId=1826%26ContentTypeId=2%26site=>
to learn more.
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>
>
--

  Douglas E. Engert  <DEEngert at anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444

Reasonably Related Threads

Search for more maybe matching threads

openssh unix dev - May 2010 - 5.2: Solaris 10 x86 x-11 forwarding fails, assign requested address

5.2: Solaris 10 x86 x-11 forwarding fails, assign requested address

5.2: Solaris 10 x86 x-11 forwarding fails, assign requested address

5.2: Solaris 10 x86 x-11 forwarding fails, assign requested address

5.2: Solaris 10 x86 x-11 forwarding fails, assign requested address

Reasonably Related Threads