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@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@cyrus.watson.org>
Reply-To: Robert Watson <robert+sec@cyrus.watson.org>
To: BUGTRAQ@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@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@ruff.cs.jmu.edu>
> If I could load the world into vi, the first command I would use is:
> %s/Windows NT//gi
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@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@cyrus.watson.org>
Reply-To: Robert Watson <robert+sec@cyrus.watson.org>
To: BUGTRAQ@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@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@ruff.cs.jmu.edu>
> If I could load the world into vi, the first command I would use is:
> %s/Windows NT//gi