Users who choose to enable X11Forwarding in OpenSSH, or those who use software products that re-enable it, should pay close attention to last Wednesday’s OpenSSH security update.
The latest version of the open source implementation of the SSH protocol patches a flaw that exposes it to command injection attacks. The open source project cautions that OpenSSH disabled X11Forwarding long ago—it is no longer the default configuration—thus limiting the risk to most users. But some vendors—OpenSSH singled out Red Hat in particular—turn X11Forwarding on and those versions prior to 7.2p2 with X11Forwarding enabled are at risk.
“Red Hat enables X11Forwarding on the server side by default, but disables it on the client side by default,” Red Hat said in a statement provided to Threatpost. “Clients should only enable it when they trust the server they are connecting to.”
Red Hat said it rated the vulnerability, CVE-2016-3115, “moderate” severity.
“A few vendors—Red Hat in particular—re-enabled the feature in their own redistribution of OpenSSH in their products, against our advice,” said OpenBSD founder and OpenSSH project leader Theo de Raadt. “We try to ship with safe defaults. They instead shipped with unsafe defaults.”
An advisory published last Wednesday by OpenSSH explains that untrusted inputs are not properly sanitized allowing an authenticated user who is able to request X11Forwarding to inject commands to xauth. An attacker could abuse this to read files as a privileged user, or use other xauth commands to leak information, overwrite files, probe ports and more.
From the OpenSSH advisory:
“As part of establishing an X11 forwarding session, sshd accepts an X11 authentication credential from the client. This credential is supplied to the xauth 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 sanitized to exclude meta-characters such as newlines. An attacker could therefore supply a credential that injected commands to xauth. 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 itself.”
De Raadt said that X11Forwarding should be enabled only on a case-by-case basis.
“OpenSSH serves many purposes: interactive logins, forwarding features, and tunnel features used in a more automated fashion,” de Raadt said. “After that time, we added some additional features to make automated services (git/rsync/etc,…) services more restricted, a variety of lockdown features. It is a similar idea—that people use the lockdown features on the accounts/services where they need it.
“With this new bug the two parts have collided,” de Raadt said. “If X11Forwarding is
enabled, the lockdown features can be bypassed.”
De Raadt said that OpenSSH has been, for two years, disabling older, insecure crypto implementations.
“We are deprecating everything we can, to avoid a ‘Heartbleed’ scenario in OpenSSH,” de Raadt said. “A few specific vendors are taking our new code, and immediately re-enabling insecure algorithms, and we believe they are simply unqualified to make those decisions.”
