5.2: Solaris 10 x86 x-11 forwarding fails, assign requested address
Douglas E. Engert
deengert at anl.gov
Tue May 25 07:41:30 EST 2010
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
More information about the openssh-unix-dev
mailing list