From ${URL} : 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. @maintainer(s): after the bump, in case we need to stabilize the package, please let us know if it is ready for the stabilization or not.
now in the tree. don't know of any reason to not stabilize. https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=a6cd19cc42eac1e72dff6585b9c83bce69048df6
Arches, please test and mark stable: =net-misc/openssh-7.2_p2 Target keywords : "alpha amd64 arm arm64 hppa ia64 m68k ppc ppc64 s390 sh sparc x86"
CVE-2016-1908: It should be noted, that the new openSSH 7.2p2 also includes the fix for CVE-2016-1908 as it had been assigned here: http://seclists.org/oss-sec/2016/q1/115 * SECURITY: Eliminate the fallback from untrusted X11-forwarding to trusted forwarding for cases when the X server disables the SECURITY extension. Reported by Thomas Hoger. The associated commit ( https://anongit.mindrot.org/openssh.git/commit/?id=ed4ce82dbfa8a3a3c8ea6fa0db113c71e234416c) did not make it into the last release as per last-minute decision (see: http://lists.mindrot.org/pipermail/openssh-unix-dev/2016-January/034684.html )
amd64 stable
Stable for HPPA PPC64.
x86 stable
Stable on alpha.
ppc stable
arm stable
Don't know if this is the right place or a new bug would be better but net-misc/openssh-7.2_p2 failes to compile when USE=hpn is set. * Messages for package net-misc/openssh-7.2_p2: * Package: net-misc/openssh-7.2_p2 * Repository: gentoo * Maintainer: base-system@gentoo.org robbat2@gentoo.org * USE: X abi_x86_64 amd64 elibc_glibc hpn kernel_linux pam pie ssl userland_GNU * FEATURES: preserve-libs sandbox splitdebug userpriv usersandbox * Sorry, but this version does not yet support features * that you requested: hpn * Please mask openssh-7.2_p2 for now and check back later: * # echo '=net-misc/openssh-7.2_p2' >> /etc/portage/package.mask * ERROR: net-misc/openssh-7.2_p2::gentoo failed (setup phase): * booooo * * Call stack: * ebuild.sh, line 133: Called pkg_setup * openssh-7.2_p2.ebuild, line 90: Called die * The specific snippet of code: * die "booooo"
Regarding the previous comment: It probably would be better to advise the user to disable the USE flag instead of masking this version as it is a matter of security…
we don't block stable for hpn. it'll come back when the update is stable.
i've done the remaining arches
Arches and Maintainer(s), Thank you for your work. New GLSA Request filed. Maintainer(s), please drop the vulnerable version(s) - 7.1_p2-r1
This issue was resolved and addressed in GLSA 201612-18 at https://security.gentoo.org/glsa/201612-18 by GLSA coordinator Aaron Bauman (b-man).
