Bug 1298741 (CVE-2016-1908) - CVE-2016-1908 openssh: possible fallback from untrusted to trusted X11 forwarding
Summary: CVE-2016-1908 openssh: possible fallback from untrusted to trusted X11 forwar...
Status: CLOSED ERRATA
Alias: CVE-2016-1908
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard: impact=moderate,public=20160114,repor...
Keywords: Security
Depends On: 1298840 1298841 1298842 1299048 1318183 1318184
Blocks: 1298744
TreeView+ depends on / blocked
 
Reported: 2016-01-14 21:48 UTC by Tomas Hoger
Modified: 2019-06-08 20:56 UTC (History)
9 users (show)

(edit)
An access flaw was discovered in OpenSSH; the OpenSSH client did not correctly handle failures to generate authentication cookies for untrusted X11 forwarding. A malicious or compromised remote X application could possibly use this flaw to establish a trusted connection to the local X server, even if only untrusted X11 forwarding was requested.
Clone Of:
(edit)
Last Closed: 2016-05-11 06:44:39 UTC


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2016:0465 normal SHIPPED_LIVE Moderate: openssh security update 2016-03-22 00:44:52 UTC
Red Hat Product Errata RHSA-2016:0741 normal SHIPPED_LIVE Moderate: openssh security, bug fix, and enhancement update 2016-05-10 22:29:45 UTC

Description Tomas Hoger 2016-01-14 21:48:58 UTC
It was discovered that OpenSSH client did not correctly handle situations when untrusted X11 forwarding was requested and generation of the untrusted authentication cookie failed.  The ssh client continued by generating fake authentication cookie and allowed remote X clients to connect the local X server.  The decision if client connection was accepted was delegated to the X server which, depending on its configuration, could allow clients to open trusted X connection.  This would lead to remote X clients having more privileged access to the local X server than intended.

This problem can occur when X server does not include or enable X Security extension (for X.org X server, this extension is not compiled in by default since 2007) and when it has authentication methods besides MIT cookies enabled (e.g. localuser authentication allowing all X connections from a local user who owns the X session).

Both of these conditions are satisfied on Red Hat Enterprise Linux 7 and current Fedora versions.  The X server does not have X Security extension compiled in and 'xhost +si:localuser:`id -un`' is run from the xinit scripts.  Therefore remote X clients are granted trusted access to the local X server when 'ssh -X' is used, as if 'ssh -Y' was actually used.

The X server on Red Hat Enterprise Linux 6 includes X Security extension (as of RHSA-2013:1620 - http://rhn.redhat.com/errata/RHSA-2013-1620.html - which was released as part of Red Hat Enterprise Linux 6.5) and hence does not fall back to the use of fake authentication cookie.

This issue was corrected upstream in version 7.1p2:

http://www.openssh.com/txt/release-7.1p2

Upstream commit:

https://anongit.mindrot.org/openssh.git/commit/?id=ed4ce82dbfa8a3a3c8ea6fa0db113c71e234416c

which needs to be applied after:

https://anongit.mindrot.org/openssh.git/commit/?id=f98a09cacff7baad8748c9aa217afd155a4d493f

Comment 1 Tomas Hoger 2016-01-14 21:50:43 UTC
This issue was originally reported upstream in Oct 2015 and the fix was waiting for inclusion in the next OpenSSH upstream release.

Comment 4 Jakub Jelen 2016-01-15 07:48:06 UTC
Actually, openssh-7.1p2 does not fix this issue and it will be as part of the next release. There was a bug in release notes:

http://lists.mindrot.org/pipermail/openssh-unix-dev/2016-January/034684.html

Comment 5 Tomas Hoger 2016-01-15 07:57:02 UTC
Thank you for pointing that error out!

Comment 6 Tomas Hoger 2016-01-15 09:08:58 UTC
Created openssh tracking bugs for this issue:

Affects: fedora-all [bug 1298840]

Comment 7 Tomas Hoger 2016-01-15 09:09:04 UTC
Created gsi-openssh tracking bugs for this issue:

Affects: fedora-all [bug 1298841]
Affects: epel-all [bug 1298842]

Comment 8 Tomas Hoger 2016-01-15 19:35:10 UTC
CVE-2016-1908 was assigned to this issue:

http://seclists.org/oss-sec/2016/q1/115

Comment 11 Fedora Update System 2016-02-10 16:51:56 UTC
gsi-openssh-7.1p2-3.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.

Comment 12 Tomas Hoger 2016-03-16 08:44:27 UTC
(In reply to Jakub Jelen from comment #4)
> Actually, openssh-7.1p2 does not fix this issue and it will be as part of
> the next release.

This issue was fixed in 7.2:

http://www.openssh.com/txt/release-7.2

Comment 14 errata-xmlrpc 2016-03-21 20:45:22 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 7

Via RHSA-2016:0465 https://rhn.redhat.com/errata/RHSA-2016-0465.html

Comment 15 errata-xmlrpc 2016-05-10 19:30:27 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 6

Via RHSA-2016:0741 https://rhn.redhat.com/errata/RHSA-2016-0741.html


Note You need to log in before you can comment on or make changes to this bug.