Bug#463011: ssh: unprivileged users may hijack forwarded X connections by listening on port 6010
On Tue, Jan 29, 2008 at 09:20:26AM +0100, Tomas Hoger wrote: According to our OpenSSH maintainer, this issue was fixed in RHEL / Fedora packages few years ago without realizing security consequences of this bug. You may want to check following patch: http://cvs.fedora.redhat.com/viewcvs/rpms/openssh/devel/openssh-3.9p1-skip-used.patch?rev=1.1view=markup which should address this problem. Thanks, and sorry I've taken so long to address this. This patch seems like the right answer to me, and will be in my next Debian upload. Do you know whether it's been forwarded upstream yet? -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#463011: ssh: unprivileged users may hijack forwarded X connections by listening on port 6010
Hi! According to our OpenSSH maintainer, this issue was fixed in RHEL / Fedora packages few years ago without realizing security consequences of this bug. You may want to check following patch: http://cvs.fedora.redhat.com/viewcvs/rpms/openssh/devel/openssh-3.9p1-skip-used.patch?rev=1.1view=markup which should address this problem. HTH -- Tomas Hoger -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#463011: ssh: unprivileged users may hijack forwarded X connections by listening on port 6010
Package: ssh Version: 1:4.3p2-9 Severity: normal Tags: security Steps to reproduce: 1) Malice logs to multiuser.example.com 2) Malice runs netcat -l -p 6010 -v -v 3) Alice logs to multuser.example.com and uses X11 forwarding (-X) 4) Alice starts emacs on the remote system (with X forwarding) Expected results: 3) ssh sets DISPLAY to :11 since :10 would make emacs talk to Malice's netcat. 4) emacs (xlib) sends MIT-MAGIC-COOKIE to $DISPLAY and Malice can't see it. Actual results: 3) ssh fails to listen on port 6010 with ipv4 localhost but does not try other ports when it can listen using ipv6: $ sudo netstat -alpn | grep 6010 tcp0 0 0.0.0.0:60100.0.0.0:* LISTEN 27820/netcat tcp6 0 0 ::1:6010:::*LISTEN 27823/15 Then ssh sets DISPLAY to :10 without telling anybody that it is actually listening only ipv6 and that malice controls the ipv4 port. 4) emacs (xlib) sends MIT-MAGIC-COOKIE to 127.0.0.1:6010 and malice's netcat can see it: listening on [any] 6010 ... connect to [127.0.0.1] from localhost [127.0.0.1] 58986 lMIT-MAGIC-COOKIE-1... More info: 1) It seems that specifying AddressFamily inet avoids the problem. 2) Easiest way to exploit this is to run vncserver :10 and allow anybody to connect to it. When alice starts her emacs it will open its window to Malice's VNC server and Malice can type M-x shell to run shell commands with privileges of alice. In fact, I initially hit this bug when the number of VNC users reached 11 and :10 was no longer available for ssh causing mysterious failures. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-4-k7 Locale: LANG=C, LC_CTYPE=fi_FI (charmap=ISO-8859-1) Versions of packages ssh depends on: ii openssh-client1:4.3p2-9 Secure shell client, an rlogin/rsh ii openssh-server1:4.3p2-9 Secure shell server, an rshd repla ssh recommends no packages. -- debconf information excluded -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
