Discussion:
OpenSSH Security Advisory: xauth command injection
(too old to reply)
Damien Miller
2016-03-10 12:10:52 UTC
Permalink
OpenSSH Security Advisory: x11fwd.adv

This document may be found at: http://www.openssh.com/txt/x11fwd.adv

1. Affected configurations

All versions of OpenSSH prior to 7.2p2 with X11Forwarding
enabled.

2. Vulnerability

Missing sanitisation of untrusted input allows an
authenticated user who is able to request X11 forwarding
to inject commands to xauth(1).

Injection of xauth commands grants the ability to read
arbitrary files under the authenticated user's privilege,
Other xauth commands allow limited information leakage,
file overwrite, port probing and generally expose xauth(1),
which was not written with a hostile user in mind, as an
attack surface.

xauth(1) is run under the user's privilege, so this
vulnerability offers no additional access to unrestricted
accounts, but could circumvent key or account restrictions
such as sshd_config ForceCommand, authorized_keys
command="..." or restricted shells.

3. Mitigation

Set X11Forwarding=no in sshd_config. This is the default.

For authorized_keys that specify a "command" restriction,
also set the "restrict" (available in OpenSSH >=7.2) or
"no-x11-forwarding" restrictions.

4. Details

As part of establishing an X11 forwarding session, sshd(8)
accepts an X11 authentication credential from the client.
This credential is supplied to the xauth(1) utility to
establish it for X11 applications that the user subsequently
runs.

The contents of the credential's components (authentication
scheme and credential data) were not sanitised to exclude
meta-characters such as newlines. An attacker could
therefore supply a credential that injected commands to
xauth(1). The attacker could then use a number of xauth
commands to read or overwrite arbitrary files subject to
file permissions, connect to local ports or perform attacks
on xauth(1) itself.

OpenSSH 7.2p2 implements a whitelist of characters that
are permitted to appear in X11 authentication credentials.

5. Credit

This issue was identified by github.com/tintinweb and
communicated to the OpenSSH developers on March 3rd, 2016.

6. Fix

Portable OpenSSH 7.2p2 contains a fix for this vulnerability.

Patches for supported OpenBSD releases (5.7, 5.8 and 5.9) have
been committed to the -STABLE branches and are available on the
errata pages:

http://www.openbsd.org/errata57.html
http://www.openbsd.org/errata58.html
http://www.openbsd.org/errata59.html
Nico Kadel-Garcia
2016-03-10 12:54:32 UTC
Permalink
Post by Damien Miller
OpenSSH Security Advisory: x11fwd.adv
This document may be found at: http://www.openssh.com/txt/x11fwd.adv
1. Affected configurations
All versions of OpenSSH prior to 7.2p2 with X11Forwarding
enabled.
2. Vulnerability
Missing sanitisation of untrusted input allows an
authenticated user who is able to request X11 forwarding
to inject commands to xauth(1).
Ouch.

I'm just trying to figure out under what normal circumstances a
connection with X11 forwarding enabled wouldn't be owned by a user who
already has normal system privileges for ssh, sftp, and scp access. I
suppose it might be an unexpected filesystem access if someone's
public SSH keys are tied to a "ForceCommand" option to run some X
based application in $HOME/.ssh/authorized_keys, and that is actually
relied on to limit access on the SSH server.

And, of course, there is an XKCD cartoon about sanitizing inputs.

https://xkcd.com/327/
Dag-Erling Smørgrav
2016-03-11 09:41:01 UTC
Permalink
Post by Nico Kadel-Garcia
I'm just trying to figure out under what normal circumstances a
connection with X11 forwarding enabled wouldn't be owned by a user who
already has normal system privileges for ssh, sftp, and scp access.
Some OS distributions (FreeBSD, RHEL / CentOS, probably Fedora) have
X11Forwarding enabled by default.

DES
--
Dag-Erling Smørgrav - ***@des.no
Nico Kadel-Garcia
2016-03-11 13:16:08 UTC
Permalink
Post by Dag-Erling Smørgrav
Post by Nico Kadel-Garcia
I'm just trying to figure out under what normal circumstances a
connection with X11 forwarding enabled wouldn't be owned by a user who
already has normal system privileges for ssh, sftp, and scp access.
Some OS distributions (FreeBSD, RHEL / CentOS, probably Fedora) have
X11Forwarding enabled by default.
DES
I'm not sure I see your point. The client connection is still
associated with a specific client user and, in most situations, their
normal SSH, scp, and sftp client privileges.

I can see where for a ForceCommand limited connection, it provides a
way to break out of the ForceCommand limitations I could see for such
configuration, setting the sshd_config or authorized_keys options to
set XauthLocation to /dev/null as well as disabling
AllowTCPForwarding, AllowAgentForwarding, AcceptEnv, etc.

Using ForceCommand securely can be tricky: this sounds like another
reason to be very cautious, and especially not to rely on it for
restricting connections for X based applications.
Dag-Erling Smørgrav
2016-03-11 14:15:03 UTC
Permalink
Post by Nico Kadel-Garcia
Post by Dag-Erling Smørgrav
Some OS distributions (FreeBSD, RHEL / CentOS, probably Fedora) have
X11Forwarding enabled by default.
I'm not sure I see your point.
With X11Forwarding off by default, one would assume that it is only
enabled on a case-by-case basis for users or groups who already have the
necessary privileges to run arbitrary code on the server and therefore
have nothing to gain from exploiting this bug. With X11Forwarding on by
default, it might remain enabled for e.g. gitolite users.

DES
--
Dag-Erling Smørgrav - ***@des.no
Nico Kadel-Garcia
2016-03-14 00:08:39 UTC
Permalink
Post by Dag-Erling Smørgrav
Post by Nico Kadel-Garcia
Post by Dag-Erling Smørgrav
Some OS distributions (FreeBSD, RHEL / CentOS, probably Fedora) have
X11Forwarding enabled by default.
I'm not sure I see your point.
With X11Forwarding off by default, one would assume that it is only
enabled on a case-by-case basis for users or groups who already have the
necessary privileges to run arbitrary code on the server and therefore
have nothing to gain from exploiting this bug. With X11Forwarding on by
default, it might remain enabled for e.g. gitolite users.
DES
OK, right. gitolite and similar tools that use ForcCommand, such as
"svn+ssh" based setups or "rsnapshot" based backup setups should be
ideally, be publishing keys with Forcecommand and
no-port-forwarding,no-X11-forwarding,no-pty" options.
Damien Miller
2016-03-14 16:36:33 UTC
Permalink
Post by Nico Kadel-Garcia
Post by Dag-Erling Smørgrav
Post by Nico Kadel-Garcia
Post by Dag-Erling Smørgrav
Some OS distributions (FreeBSD, RHEL / CentOS, probably Fedora) have
X11Forwarding enabled by default.
I'm not sure I see your point.
With X11Forwarding off by default, one would assume that it is only
enabled on a case-by-case basis for users or groups who already have the
necessary privileges to run arbitrary code on the server and therefore
have nothing to gain from exploiting this bug. With X11Forwarding on by
default, it might remain enabled for e.g. gitolite users.
OK, right. gitolite and similar tools that use ForcCommand, such as
"svn+ssh" based setups or "rsnapshot" based backup setups should be
ideally, be publishing keys with Forcecommand and
no-port-forwarding,no-X11-forwarding,no-pty" options.
better to use "restrict" if you're running a recent OpenSSH

Loading...