YO All! Have you guys been following the SSH discussion on Bugtraq lately? I like their idea the X forwarding should be OFF by default on the client. RGDS GARY --------------------------------------------------------------------------- Gary E. Miller Rellim 20340 Empire Ave, Suite E-3, Bend, OR 97701 gem at rellim.com Tel:+1(541)382-8588 Fax: +1(541)382-8676 ---------- Forwarded message ---------- Date: Fri, 25 Feb 2000 21:52:15 -0500 From: Robert Watson <robert at cyrus.watson.org> Reply-To: Robert Watson <robert+sec at cyrus.watson.org> To: BUGTRAQ at SECURITYFOCUS.COM Subject: Re: SSH & xauth This is a very round-about way of observing that allowing X11 forwarding from a client to any untrusted server (by any means -- sshd, xauth, common accounts, poor file permissions, compromised kernel, etc, etc) with the current SSH clients results in security problems (which you observe). What's more curious is that in OpenSSH, which I observed some time ago, the default configuration is to enable X11 forwarding in the client and disable it in the server. This is, of course, backwards, as the client is the one accepting risk by forwarding X11, not the server. :-) If you search back a few years in the bugtraq archives, you'll see that one suggestion for dealing with this, and still allowing X11 forwarding from untrusted clients, is to use the Xnest server, limiting access by the ssh client to that DISPLAY. As I observed at the time, Xnest was probably not designed with this use in mind, and as such is probably ``breakable,'' meaning that a pursuaded party might be able to gain access to the proper display through exploiting weaknesses in the Xnest server. I have not audited the Xnest code to verify that this is or is not the case. I believe at the time, Alan Cox responded with information about using the Broadway extensions to limit access by specific applications to other X11 applications, the X event queue, etc. These messages were circa 1997, and should appear in bugtraq archives. Presumably the correct configuration is for clients to disable X11 by default, and only have it enabled specifically by the user via appropriate flags to ssh, or via the config file. You could imagine a more comprehensive interface to new host key adoption that also inquired as to a trust level for X11 forwarding using Broadway, etc. In this manner, the user could specify ``limited'' access that would be sandboxed, not allowing access to screen data, X event queue access, etc, ``full,'' or ``none.'' With a little imagination, you could even imagine it spawning an Xnest to generate a sandbox for remote access. I would conclude by observing that this is *very* old news--the only new news is that it has not yet been ``fixed.'' Of course, there's a decent argument that many consumers of SSH are the kind of people who also blindly accept new hostkeys without verifying fingerprints or using a PKI, so this kind of default won't help them at all, just causing frustration. :-) If you want another puzzling OpenSSH tidbit, it's that the CheckIP option is enabled by default in the base implementation. It has recently been turned off in the FreeBSD version for the following reason (which was rejected by OpenSSH developers shortly after OpenSSH was released). The CheckHostIP feature introduces automatic modification of the known hosts key file to include the IP address of the host after connecting by name. This option introduces unnecessary modifications of keying material entries, and can cause spurious keying errors following IP address changes, especially in a dynamic DNS/IP allocation environment. When a user requests a connection by-name, the key storage should be by-name, as SSH is not aware of whether or not the name/key binding is persistent. Presumably, just as the user is responsible for performing by-name key verification and management, the user should also be responsible for managing by-number key verification and management. This also causes management problems for hosts employing centralized ssh_known_hosts entries--SSH replicates the key from the central file into the user's personal key file using the IP address to index the key. If the IP of the host is a variable IP, putting the IP into the centralized file makes no sense, but SSH will take the liberty of?replicating the keying material unnecessarily. If a host key now changes, and the centralized file is updated to reflect it, SSH will now generate warnings as its spuriously replicated key no longer matches up. You can even imagine DNS-based spoofing causing some problems, if combined with IP spoofing, as ssh-by-ip to a spoofed host would not generate an unknown key warning, instead, it would connect with full trust. This attack is a little of a stretch on convenience for the attacker, but is feasible. The end conclusion is really that key introduction for key indexes (names, IPs) should only occur when specifically authorized by the user and following a fingerprint display, never automatically. Robert N M Watson robert at fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services On Thu, 24 Feb 2000, Brian Caswell wrote:> The default SSH configuration for SSH1 and SSH2 allow for remote > controlling of X sessions through X forwarding. > > All children of the SSH connection are able to tunnel X11 sessions > through the X tunnel to the client X11 session. This is accomplished > by running xauth upon logging in. > > If xauth is replaced on the server by a malicious program that does > both of the following: > - runs xauth, adding in the "correct" information allowing the > children of the session to tunnel X11 programs through the SSH > session > - runs xauth, adding in the "malicious" information, allowing a > malicious source to tunnel X11 programs through the SSH session. > > With the added data in .Xauthority, a malicious source can fully control > the client X session. The malicious source can then do most anything to > the X session, from logging keystrokes of the X session, to taking > screen captures, to typing in commands to open terminals. > > The only thing that is required for the client system to be compromised > is for the client to remotely log via ssh (with X11 forwarding enabled) > into a compromised server. > > Allowing X forwarding seems to be turned on by default in SSH1, SSH2, > and OpenSSH. > > To fix this "issue" add the following lines to the SSH client > configuration. ($HOME/.ssh/config or ssh_config) > > > Host * > ForwardX11 no > > > Discussions of security flaws within X11 have been going on for years. > The "issue" in SSH X11 forwarding is not new. SSH has added to the > security of X11, but by no means does the use of SSH secure X11. > > -- > Brian Caswell <cazz at ruff.cs.jmu.edu> > If I could load the world into vi, the first command I would use is: > %s/Windows NT//gi
On Mon, 28 Feb 2000, Gary E. Miller wrote:> YO All! > > Have you guys been following the SSH discussion on Bugtraq lately? > > I like their idea the X forwarding should be OFF by default on the > client.In the default config which ships with 1.2.2 it is. -d -- | "Bombay is 250ms from New York in the new world order" - Alan Cox | Damien Miller - http://www.mindrot.org/ | Email: djm at mindrot.org (home) -or- djm at ibs.com.au (work)
I have a suggestion that I think would be useful to implement. People who have seen the Firewall Toolkit's X proxy will find this suggestion familiar. The fwtk provides a small proxy that users set their DISPLAY to. Whenever a new connection is initiated to that proxy, the proxy pops-up a dialog box on the user's real DISPLAY. The user must agree to accept that incoming connection before the proxy will forward the data from it. The ssh client could be made to, whenever an X tunnel was opened, run an external dialog program, before the client would accept the tunnel. Depending on the exit status of that program, the connection would either be allowed on rejected. Presumably this functionality would be optional (but perhaps enabled by default). Of course there is a tendancy for users to treat dialog boxes as a reflex test and to click them without reading them. However, this mechanism does provide a way for cautious users to enable X forwarding without blindly allowing all X clients to connect. Comments, ambitious coders? On Mon, 28 Feb 2000, Gary E. Miller wrote:> Have you guys been following the SSH discussion on Bugtraq lately? > > I like their idea the X forwarding should be OFF by default on the > client. > > RGDS > GARY > --------------------------------------------------------------------------- > Gary E. Miller Rellim 20340 Empire Ave, Suite E-3, Bend, OR 97701 > gem at rellim.com Tel:+1(541)382-8588 Fax: +1(541)382-8676 > > ---------- Forwarded message ---------- > Date: Fri, 25 Feb 2000 21:52:15 -0500 > From: Robert Watson <robert at cyrus.watson.org> > Reply-To: Robert Watson <robert+sec at cyrus.watson.org> > To: BUGTRAQ at SECURITYFOCUS.COM > Subject: Re: SSH & xauth > > This is a very round-about way of observing that allowing X11 forwarding > from a client to any untrusted server (by any means -- sshd, xauth, common > accounts, poor file permissions, compromised kernel, etc, etc) with the > current SSH clients results in security problems (which you observe). > > What's more curious is that in OpenSSH, which I observed some time ago, > the default configuration is to enable X11 forwarding in the client and > disable it in the server. This is, of course, backwards, as the client is > the one accepting risk by forwarding X11, not the server. :-) > > If you search back a few years in the bugtraq archives, you'll see that > one suggestion for dealing with this, and still allowing X11 forwarding > from untrusted clients, is to use the Xnest server, limiting access by the > ssh client to that DISPLAY. As I observed at the time, Xnest was probably > not designed with this use in mind, and as such is probably ``breakable,'' > meaning that a pursuaded party might be able to gain access to the proper > display through exploiting weaknesses in the Xnest server. I have not > audited the Xnest code to verify that this is or is not the case. > > I believe at the time, Alan Cox responded with information about using the > Broadway extensions to limit access by specific applications to other X11 > applications, the X event queue, etc. These messages were circa 1997, and > should appear in bugtraq archives. > > Presumably the correct configuration is for clients to disable X11 by > default, and only have it enabled specifically by the user via appropriate > flags to ssh, or via the config file. You could imagine a more > comprehensive interface to new host key adoption that also inquired as to > a trust level for X11 forwarding using Broadway, etc. In this manner, the > user could specify ``limited'' access that would be sandboxed, not > allowing access to screen data, X event queue access, etc, ``full,'' or > ``none.'' With a little imagination, you could even imagine it spawning > an Xnest to generate a sandbox for remote access. > > I would conclude by observing that this is *very* old news--the only new > news is that it has not yet been ``fixed.'' Of course, there's a decent > argument that many consumers of SSH are the kind of people who also > blindly accept new hostkeys without verifying fingerprints or using a PKI, > so this kind of default won't help them at all, just causing frustration. > :-) > > If you want another puzzling OpenSSH tidbit, it's that the CheckIP option > is enabled by default in the base implementation. It has recently been > turned off in the FreeBSD version for the following reason (which was > rejected by OpenSSH developers shortly after OpenSSH was released). > > The CheckHostIP feature introduces automatic modification of the known > hosts key file to include the IP address of the host after connecting by > name. This option introduces unnecessary modifications of keying material > entries, and can cause spurious keying errors following IP address > changes, especially in a dynamic DNS/IP allocation environment. When a > user requests a connection by-name, the key storage should be by-name, as > SSH is not aware of whether or not the name/key binding is persistent. > Presumably, just as the user is responsible for performing by-name key > verification and management, the user should also be responsible for > managing by-number key verification and management. > > This also causes management problems for hosts employing centralized > ssh_known_hosts entries--SSH replicates the key from the central file into > the user's personal key file using the IP address to index the key. If > the IP of the host is a variable IP, putting the IP into the centralized > file makes no sense, but SSH will take the liberty of?replicating the > keying material unnecessarily. If a host key now changes, and the > centralized file is updated to reflect it, SSH will now generate warnings > as its spuriously replicated key no longer matches up. > > You can even imagine DNS-based spoofing causing some problems, if combined > with IP spoofing, as ssh-by-ip to a spoofed host would not generate an > unknown key warning, instead, it would connect with full trust. This > attack is a little of a stretch on convenience for the attacker, but is > feasible. The end conclusion is really that key introduction for key > indexes (names, IPs) should only occur when specifically authorized by the > user and following a fingerprint display, never automatically. > > Robert N M Watson > > robert at fledge.watson.org http://www.watson.org/~robert/ > PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 > TIS Labs at Network Associates, Safeport Network Services > > > On Thu, 24 Feb 2000, Brian Caswell wrote: > > > The default SSH configuration for SSH1 and SSH2 allow for remote > > controlling of X sessions through X forwarding. > > > > All children of the SSH connection are able to tunnel X11 sessions > > through the X tunnel to the client X11 session. This is accomplished > > by running xauth upon logging in. > > > > If xauth is replaced on the server by a malicious program that does > > both of the following: > > - runs xauth, adding in the "correct" information allowing the > > children of the session to tunnel X11 programs through the SSH > > session > > - runs xauth, adding in the "malicious" information, allowing a > > malicious source to tunnel X11 programs through the SSH session. > > > > With the added data in .Xauthority, a malicious source can fully control > > the client X session. The malicious source can then do most anything to > > the X session, from logging keystrokes of the X session, to taking > > screen captures, to typing in commands to open terminals. > > > > The only thing that is required for the client system to be compromised > > is for the client to remotely log via ssh (with X11 forwarding enabled) > > into a compromised server. > > > > Allowing X forwarding seems to be turned on by default in SSH1, SSH2, > > and OpenSSH. > > > > To fix this "issue" add the following lines to the SSH client > > configuration. ($HOME/.ssh/config or ssh_config) > > > > > > Host * > > ForwardX11 no > > > > > > Discussions of security flaws within X11 have been going on for years. > > The "issue" in SSH X11 forwarding is not new. SSH has added to the > > security of X11, but by no means does the use of SSH secure X11. > > > > -- > > Brian Caswell <cazz at ruff.cs.jmu.edu> > > If I could load the world into vi, the first command I would use is: > > %s/Windows NT//gi >-- Mike Fisk, RADIANT Team, Network Engineering Group, Los Alamos National Lab See http://home.lanl.gov/mfisk/ for contact information
On Fri, 3 Mar 2000, Sean Aaron Lisse wrote:> > I have a suggestion that I think would be useful to implement. > > People who have seen the Firewall Toolkit's X proxy will find this > > suggestion familiar. The fwtk provides a small proxy that users set their > > DISPLAY to. Whenever a new connection is initiated to that proxy, the > > proxy pops-up a dialog box on the user's real DISPLAY. The user must > > agree to accept that incoming connection before the proxy will forward the > > data from it. > > My main objection to this would be that it's dependent upon the dialog-box > program's presence. You're tying down X forwarding to the > presence/absence of another (perhaps machine-specific!) program in the > system, and perhaps the compilation of SSH to the presence of X at all. > > Not a wonderful idea for a uniform text-based suite like SSH. I'd have > no problems at all if SSH was originally designed to be GUI with adding > another dialog box. Since it's not, however, I'd argue against it.I wasn't been paying complete attention, but there have been some threads on this list about the X programs (ssh-askpass, etc.) that prompt for passwords. I would assume that this dialog box would be provided the same way that that functionality is provided (however that is or isn't bundled). The client could issue a text prompt in the tty, but that disrupts whatever output is on that window (which might also be iconified and ignored). -- Mike Fisk, RADIANT Team, Network Engineering Group, Los Alamos National Lab See http://home.lanl.gov/mfisk/ for contact information
Possibly Parallel Threads
- CESA-2008:0030 Important CentOS 4 s390(x) xorg-x11 - security update
- X11forwarding yes: how to debug/setup after xauth fix
- CESA-2008:0029 Important CentOS 3 s390(x) XFree86 - security update
- CESA-2008:0030 Important CentOS 4 ia64 xorg-x11 - security update
- X11forwarding yes: how to debug/setup after xauth fix