File: [local] / www / openssh / security.html (download) (as text)
Revision 1.75, Sat Apr 20 22:10:39 2024 UTC (5 weeks, 3 days ago) by bentley
Branch: MAIN
CVS Tags: HEAD
Changes since 1.74: +6 -6 lines
Fix minor syntax errors that crept in.
|
<!doctype html>
<html lang=en>
<meta charset=utf-8>
<title>OpenSSH: Security</title>
<meta name="description" content="OpenSSH advisories">
<meta name="viewport" content="width=device-width, initial-scale=1">
<link rel="stylesheet" type="text/css" href="openbsd.css">
<link rel="canonical" href="https://www.openssh.com/security.html">
<style>
li {
margin-bottom: 1em;
}
</style>
<h2 id=OpenBSD>
<a href="/">
<i>Open</i><b>SSH</b></a>
Security
</h2>
<hr>
<p>
OpenSSH is developed with the same rigorous security process that the
OpenBSD group is famous for. If you wish to report a security issue in
OpenSSH, please contact the private developers list <<a href="mailto:openssh@openssh.com">openssh@openssh.com</a>>.
<p>
For more information, see the
<a href="https://www.openbsd.org/security.html">OpenBSD security page</a>.
<ul>
<li><p><b>December 18, 2023</b><br>
ssh(1), sshd(8) in OpenSSH prior to version 9.6.
<br>
Weakness in initial key exchange ("Terrapin Attack")
<br>
A weakness in the initial SSH protocol key exchange allows an
on-path attacker to delete a number of consecutive messages from
the early encrypted protocol without detection. While cryptographically
novel, there is no discernable impact on the integrity of SSH traffic
beyond giving the attacker the ability to delete the message that
enables some features related to keystroke timing obfuscation.
<br>
This attack is prevented by a new protocol extension in OpenSSH 9.6.
<br>
For more information, please refer to the
<a href="txt/release-9.6">release notes</a>.
<li><p><b>December 18, 2023</b><br>
ssh-agent(1) in OpenSSH between 8.9 and 9.5 (inclusive)
<br>
Incomplete application of destination constraints to smartcard keys.
<br>
Destination constraints added when loading PKCS#11 keys from a token
were being applied to only the first key returned from the token.
<br>
This bug is corrected in OpenSSH 9.6.
<br>
For more information, please refer to the
<a href="txt/release-9.6">release notes</a>.
<li><p><b>July 19, 2023</b><br>
ssh-agent(1) in OpenSSH between and 5.5 and 9.3p1 (inclusive)
remote code execution relating to PKCS#11 providers
<br>
The PKCS#11 support ssh-agent(1) could be abused to achieve remote
code execution via a forwarded agent socket if the following conditions
are met:
<ul>
<li>Exploitation requires the presence of specific libraries on the victim system.</li>
<li>Remote exploitation requires that the agent was forwarded to an attacker-controlled system.</li>
</ul>
Exploitation can also be prevented by starting ssh-agent(1) with an
empty PKCS#11/FIDO allowlist (ssh-agent -P '') or by configuring
an allowlist that contains only specific provider libraries.
<br>
This vulnerability was discovered and demonstrated to be exploitable
by the Qualys Security Advisory team. This vulnerability has been
assigned CVE-2023-38408.
<br>
This bug is corrected in OpenSSH 9.3p2. For OpenBSD, an
<a href="https://www.openbsd.org/errata.html">errata</a>
patch exists to fix this problem.
<br>
For more information, please refer to the
<a href="txt/release-9.3p2">release notes</a>.
<li><p><b>March 15, 2023</b><br>
ssh-add(1) in OpenSSH between and 8.9 and 9.2 (inclusive).
<br>
ssh-add(1) did not apply destination constraints to smartcard keys.
<br>
When adding smartcard keys to ssh-agent(1) with the per-hop destination
constraints (<em>ssh-add -h ...</em>), a logic error prevented the
constraints from being communicated to the agent. This resulted in the
keys being added without constraints. The common cases of
non-smartcard keys and keys without destination constraints are
unaffected.
<br>
This bug is corrected in OpenSSH 9.3.
<br>
For more information, please refer to the
<a href="txt/release-9.3">release notes</a>.
<li><p><b>February 2, 2023</b><br>
ssh(1) in OpenSSH between and 8.7 and 9.1 (inclusive).
<br>
ssh(1) failed to correctly process PermitRemoteOpen options.
<br>
The PermitRemoteOpen option
would ignore its first argument unless it was one of the special
keywords "any" or "none", causing the permission list to fail open
if only one permission was specified.
<br>
This bug is corrected in OpenSSH 9.2.
<br>
For more information, please refer to the
<a href="txt/release-9.2">release notes</a>.
<li><p><b>February 2, 2023</b><br>
ssh(1) in OpenSSH between and 6.5 and 9.1 (inclusive).
<br>
ssh(1) failed to check DNS names returned from libc for validity.
<br>
If the CanonicalizeHostname and CanonicalizePermittedCNAMEs
options were enabled, and the system/libc resolver did not check
that names in DNS responses were valid, then use of these options
could allow an attacker with control of DNS to include invalid
characters (possibly including wildcards) in names added to
known_hosts files when they were updated. These names would still
have to match the CanonicalizePermittedCNAMEs allow-list, so
practical exploitation appears unlikely.
<br>
This bug is corrected in OpenSSH 9.2.
<br>
For more information, please refer to the
<a href="txt/release-9.2">release notes</a>.
<li><p><b>February 2, 2023</b><br>
sshd in OpenSSH between and 9.1 (only).
<br>
Double-free memory fault in pre-authentication sshd process.
<br>
sshd(8) contained a network-reachable pre-authentication double-free
memory fault introduced in OpenSSH 9.1. This is not believed to be
exploitable, and it occurs in the unprivileged pre-auth process that is
subject to chroot(2) and is further sandboxed on most major
platforms.
<br>
This bug is corrected in OpenSSH 9.2.
<br>
For more information, please refer to the
<a href="txt/release-9.2">release notes</a>.
<li><p><b>September 26, 2021</b><br>
sshd in OpenSSH between 6.2 and 8.7 (inclusive).
<br>
sshd(8) failed to correctly initialise supplemental groups when
executing an <code>AuthorizedKeysCommand</code> or
<code>AuthorizedPrincipalsCommand</code>, where a
<code>AuthorizedKeysCommandUser</code> or
<code>AuthorizedPrincipalsCommandUser</code> directive was been set to
run the command as a non-root user. Instead these commands would inherit
the groups that sshd(8) was started with.
<br>
Depending on system configuration, inherited groups may allow
the helper programs to gain unintended privilege.
<br>
Neither <code>AuthorizedKeysCommand</code> nor
<code>AuthorizedPrincipalsCommand</code> are enabled by default in
sshd_config(5).
<br>
This bug is corrected in OpenSSH 8.8
<br>
For more information, please refer to the
<a href="txt/release-8.8">release notes</a>.
<li><p><b>March 3, 2021</b><br>
ssh-agent in OpenSSH between 8.2 and 8.4 (inclusive).
<br>
Double-free memory corruption. Mitigated by socket peer user identity
checking and double-free protection in malloc(3).
This bug is corrected in OpenSSH 8.5
For more information, please refer to the
<a href="txt/release-8.5">release notes</a>.
<li><p><b>October 3, 2017</b><br>
All version of OpenSSH prior to 7.6 supporting read-only mode in sftp-server
(introduced in 5.5).
Incorrect open(2) flags in sftp-server permitted creation
of zero-length files when the server was running in read-only mode (invoked
using the -R command-line flag).
<br>
This bug is corrected in OpenSSH 7.6.
For more information, please refer to the
<a href="txt/release-7.6">release notes</a>.
<li><p><b>March 9, 2016</b><br>
All versions of OpenSSH prior to 7.2p2 with X11Forwarding
enabled.
Missing sanitisation of untrusted input allows an
authenticated user who is able to request X11 forwarding
to inject commands to xauth(1).
<p>
Mitigate by setting <b>X11Forwarding=no</b> in sshd_config, or on the
commandline. This is the default, but some vendors enable the feature.
<p>
For more information see <a href="txt/x11fwd.adv">the advisory</a>.
<br>
This bug is corrected in OpenSSH 7.2p2 and in OpenBSD's stable branch.
For more information, please
refer to the <a href="txt/release-7.2p2">release notes</a>.
<li><p><b>January 14, 2016</b><br>
OpenSSH clients between versions 5.4 and 7.1 are vulnerable to
information disclosure that may allow a malicious server to retrieve
information including under some circumstances, user's private keys.
This may be mitigated by adding the undocumented config option
<b>UseRoaming no</b> to ssh_config.<br>
For more information see <a
href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-0777"
>CVE-2016-0777</a> and <a
href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-0778"
>CVE-2016-0778</a>. <br>
This bug is corrected in OpenSSH 7.1p2 and in OpenBSD's stable branch.
For more information, please
refer to the <a href="txt/release-7.1p2">release notes</a>.
<li><p><b>August 21, 2015</b><br>
OpenSSH 7.0 contained a logic error in PermitRootLogin=
prohibit-password/without-password that could, depending on
compile-time configuration, permit password authentication to
root while preventing other forms of authentication.<br>
This bug is corrected in OpenSSH 7.1. For more information, please
refer to the <a href="https://www.openssh.com/txt/release-7.1">release
notes</a>
<li><p><b>August 11, 2015</b><br>
OpenSSH 6.7 through 6.9 assign weak permissions to TTY devices.<br>
Keyboard-interactive authentication in OpenSSH prior to 7.0 may
allow circumvention of MaxAuthTries.<br>
These bugs are corrected in OpenSSH 7.0. For more information, please
refer to the <a href="https://www.openssh.com/txt/release-7.0">release
notes</a>
<li><p><b>June 30, 2015</b><br>
OpenSSH prior to 6.9 suffered from a race condition that could allow
non-trusted X11 forwarding sessions to be treated as trusted.
For more information, please
refer to the <a href="https://www.openssh.com/txt/release-6.9">release
notes</a>
<li><p><b>November 8, 2013:</b><br>
OpenSSH versions 6.2 and 6.3 are vulnerable to the memory corruption
problem described in the
<a href="https://www.openssh.com/txt/gcmrekey.adv">gcmrekey.adv</a> advisory
and the
<a href="https://www.openssh.com/txt/release-6.4">OpenSSH 6.4 release notes</a>.
<li><p><b>February 2, 2011:</b><br>
Portable OpenSSH prior to version 5.8p2 is vulnerable to the local
host key theft attack described in
<a href="https://www.openssh.com/txt/portable-keysign-rand-helper.adv">portable-keysign-rand-helper.adv</a> advisory
and the
<a href="https://www.openssh.com/txt/release-5.8p2">OpenSSH 5.8p2 release notes</a>.
<li><p><b>January 24, 2011:</b><br>
OpenSSH versions 5.6 and 5.7 are vulnerable to a potential leak of
private key data described in the
<a href="https://www.openssh.com/txt/legacy-cert.adv">legacy-cert.adv</a> advisory
and the
<a href="https://www.openssh.com/txt/release-5.8">OpenSSH 5.8 release notes</a>.
<li><p><b>February 23, 2009:</b><br>
OpenSSH prior to version 5.2 is vulnerable to the protocol
weakness described in
<a href="http://www.cpni.gov.uk/Docs/Vulnerability_Advisory_SSH.txt">CPNI-957037 "Plaintext Recovery Attack Against SSH"</a>.
However, based on the limited information available it appears that this
described attack is infeasible in most circumstances. For more
information please refer to the
<a href="https://www.openssh.com/txt/cbc.adv">cbc.adv</a> advisory
and the
<a href="https://www.openssh.com/txt/release-5.2">OpenSSH 5.2 release notes</a>.
<li><p><b>July 22, 2008:</b><br>
Portable OpenSSH 5.1 and newer are not vulnerable to the X11UseLocalhost=no hijacking attack
on HP/UX (and possibly other systems) described in the
<a href="https://www.openssh.com/txt/release-5.1">OpenSSH 5.1 release notes</a>.
<li><p><b>April 3, 2008:</b><br>
OpenSSH 5.0 and newer are not vulnerable to the X11 hijacking attack
described in
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1483">CVE-2008-1483</a> and the
<a href="https://www.openssh.com/txt/release-5.0">OpenSSH 5.0 release notes</a>.
<li><p><b>March 31, 2008:</b><br>
OpenSSH 4.9 and newer do not execute ~/.ssh/rc for sessions whose command
has been overridden with a sshd_config(5) <em>ForceCommand</em> directive.
This was a documented, but unsafe behaviour (described in
<a href="https://www.openssh.com/txt/release-4.9">OpenSSH 4.9 release notes</a>).
<li><p><b>September 5, 2007:</b><br>
OpenSSH 4.7 and newer do not fall back to creating trusted X11
authentication cookies when untrusted cookie generation fails (e.g. due to
deliberate resource exhaustion), as described in the
<a href="https://www.openssh.com/txt/release-4.7">OpenSSH 4.7 release notes</a>.
<li><p><b>November 7, 2006:</b><br>
OpenSSH 4.5 and newer fix a weakness in the privilege separation monitor
that could be used to spoof successful authentication (described in the
<a href="https://www.openssh.com/txt/release-4.5">OpenSSH 4.5 release notes</a>).
Note that exploitation of this vulnerability would require an attacker to
have already subverted the network-facing sshd(8) process, and no
vulnerabilities permitting this are known.
<li><p><b>September 27, 2006:</b><br>
OpenSSH 4.4 and newer is not vulnerable to the unsafe signal handler
vulnerability described in the
<a href="https://www.openssh.com/txt/release-4.4">OpenSSH 4.4 release notes</a>.
<li><p><b>September 27, 2006:</b><br>
OpenSSH 4.4 and newer is not vulnerable to the SSH protocol 1 denial of
service attack described in the
<a href="https://www.openssh.com/txt/release-4.4">OpenSSH 4.4 release notes</a>.
<li><p><b>February 1, 2006:</b><br>
OpenSSH 4.3 and newer are not vulnerable to shell metacharacter expansion
in scp(1) local-local and remote-remote copies
(<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0225">CVE-2006-0225</a>), as described in the
<a href="https://www.openssh.com/txt/release-4.3">OpenSSH 4.3 release notes</a>.
<li><p><b>September 1, 2005:</b><br>
OpenSSH 4.2 and newer does not allow delegation of GSSAPI credentials
after authentication using a non-GSSAPI method as described in the
<a href="https://www.openssh.com/txt/release-4.2">OpenSSH 4.2 release notes</a>.
<li><p><b>September 1, 2005:</b><br>
OpenSSH 4.2 and newer do not incorrectly activate GatewayPorts for
dynamic forwardings (bug introduced in OpenSSH 4.0) as described in the
<a href="https://www.openssh.com/txt/release-4.2">OpenSSH 4.2 release notes</a>.
<li><p><b>September 16, 2003:</b><br>
Portable OpenSSH 3.7.1p2 and newer are not vulnerable to
"September 23, 2003: Portable OpenSSH Multiple PAM vulnerabilities",
<a href="https://www.openssh.com/txt/sshpam.adv">OpenSSH
Security Advisory</a>. (This issue does not affect OpenBSD versions)
<li><p><b>September 16, 2003:</b><br>
OpenSSH 3.7.1 and newer are not vulnerable to
"September 16, 2003: OpenSSH Buffer Management bug",
<a href="https://www.openssh.com/txt/buffer.adv">OpenSSH
Security Advisory</a> and CERT Advisory
<a href="http://www.cert.org/advisories/CA-2003-24.html">CA-2003-24</a>.
<li><p><b>August 1, 2002:</b><br>
OpenSSH version 3.2.2p1, 3.4p1 and 3.4 were trojaned on the
OpenBSD FTP server and potentially propagated via the normal
mirroring process to other FTP servers. The code was inserted
some time between the 30th and 31th of July. We replaced the
trojaned files with their originals at 7AM MDT, August 1st:
<a href="https://www.openbsd.org/advisories/ssh_trojan.txt">OpenBSD
Advisory</a>.
<li><p><b>June 26, 2002:</b><br>
OpenSSH 3.4 and newer are not vulnerable to
"June 26, 2002: OpenSSH Remote Challenge Vulnerability",
<a href="https://www.openssh.com/txt/preauth.adv">OpenSSH
Security Advisory</a>.
<li><p><b>March 29, 2002:</b><br>
OpenSSH 3.2.1 and newer are not vulnerable to
"April 21, 2002: Buffer overflow in AFS/Kerberos token passing code",
<a href="https://www.openbsd.org/advisories/ssh_afstoken.txt">OpenSSH
Security Advisory</a>:
Versions prior to OpenSSH 3.2.1 allow privileged access if
AFS/Kerberos token passing is compiled in and enabled (either
in the system or in sshd_config).
<li><p><b>March 7, 2002:</b><br>
OpenSSH 3.1 and newer are not vulnerable to
"March 7, 2002: Off-by-one error in the channel code",
<a href="https://www.openbsd.org/advisories/ssh_channelalloc.txt">OpenSSH
Security Advisory</a>.
<li><p><b>November 24, 2001:</b><br>
OpenSSH 3.0.2 and newer do not
allow users to <a href="http://www.kb.cert.org/vuls/id/157447">
pass environment variables to login(1) if UseLogin is enabled</a>.
The UseLogin option is disabled by default in all OpenSSH releases.
<li><p><b>May 21, 2001:</b><br>
OpenSSH 2.9.9 and newer are not vulnerable to
"Sep 26, 2001: Weakness in OpenSSH's source IP based access control
for SSH protocol v2 public key authentication.",
<a href="https://www.openbsd.org/advisories/ssh_option.txt">OpenSSH
Security Advisory</a>.
<li><p><b>May 21, 2001:</b><br>
OpenSSH 2.9.9 and newer do not
allow users to <a href="http://www.kb.cert.org/vuls/id/655259">
delete files named "cookies" if X11 forwarding is enabled</a>.
X11 forwarding is disabled by default.
<li><p><b>November 6, 2000:</b><br>
OpenSSH 2.3.1, a development snapshot which was never released, was
vulnerable to
"Feb 8, 2001: Authentication By-Pass Vulnerability in OpenSSH-2.3.1",
<a href="https://www.openbsd.org/advisories/ssh_bypass.txt">OpenBSD
Security Advisory</a>.
In protocol 2, authentication could be bypassed if public key
authentication was permitted. This problem does exist only
in OpenSSH 2.3.1, a three week internal development release.
OpenSSH 2.3.0 and versions newer than 2.3.1 are not vulnerable to
this problem.
<li><p><b>November 6, 2000:</b><br>
OpenSSH 2.3.0 and newer do not allow
<a href="http://www.kb.cert.org/vuls/id/363181">
malicious servers to access the client's X11 display or ssh-agent</a>.
This problem has been fixed in OpenSSH 2.3.0.
<li><p><b>November 6, 2000:</b><br>
OpenSSH 2.3.0 and newer are not vulnerable to the
"Feb 8, 2001: SSH-1 Daemon CRC32 Compensation Attack Detector Vulnerability",
<a href="http://razor.bindview.com/publish/advisories/adv_ssh1crc.html">RAZOR Bindview Advisory CAN-2001-0144</a>.
A buffer overflow in the CRC32 compensation attack detector can
lead to remote root access. This problem has been fixed in
OpenSSH 2.3.0. However, versions prior to 2.3.0 are vulnerable.
<li><p><b>September 2, 2000:</b><br>
OpenSSH 2.2.0 and newer are not vulnerable to the
"Feb 7, 2001: SSH-1 Session Key Recovery Vulnerability",
CORE-SDI Advisory CORE-20010116. OpenSSH imposes limits on the
connection rate, making the attack unfeasible. Additionally, the
Bleichenbacher oracle has been closed completely since January 29,
2001.
<li><p><b>June 8, 2000:</b><br>
OpenSSH 2.1.1 and newer do not allow a remote attacker to
<a href="http://www.kb.cert.org/vuls/id/40327">
execute arbitrary commands with the privileges of sshd if UseLogin</a>
is enabled by the administrator. UseLogin is disabled by default.
This problem has been fixed in OpenSSH 2.1.1.
<li><p>OpenSSH was never vulnerable to the
"Feb 5, 2001: SSH-1 Brute Force Password Vulnerability",
<a href="http://www.crimelabs.net/">Crimelabs Security Note CLABS200101</a>.
<li><p>OpenSSH was not vulnerable to the RC4 cipher
<a href="http://www.kb.cert.org/vuls/id/565052">password cracking</a>,
<a href="http://www.kb.cert.org/vuls/id/665372">replay</a>, or
<a href="http://www.kb.cert.org/vuls/id/25309">modification</a>
attacks. At the time that OpenSSH was started, it was already known
that SSH 1 used the RC4 stream cipher completely incorrectly, and
thus RC4 support was removed.
<li><p>OpenSSH was not vulnerable to
<a href="http://www.kb.cert.org/vuls/id/684820">client forwarding attacks</a>
in unencrypted connections, since unencrypted connection support was
removed at OpenSSH project start.
<li><p>OpenSSH was not vulnerable to IDEA-encryption algorithm
<a href="http://www.kb.cert.org/vuls/id/315308">attacks on the last packet</a>,
since the IDEA algorithm is not supported. The patent status of IDEA makes
it unsuitable for inclusion in OpenSSH.
<li><p>OpenSSH does not treat localhost as exempt from host key checking,
thus making it not vulnerable to the
<a href="http://www.kb.cert.org/vuls/id/786900">host key authentication bypass</a>
attack.
<li><p>OpenSSH was not vulnerable to
<a href="http://www.kb.cert.org/vuls/id/118892">uncontrollable X11 forwarding</a>
attacks because X11-forwarding is disabled by default and the user can
de-permit it.
<li><p>OpenSSH has the SSH 1 protocol deficiency that might make an insertion attack
difficult but possible. The CORE-SDI
<a href="http://www2.corest.com/common/showdoc.php?idx=131&idxseccion=10">deattack mechanism</a>
is used to eliminate
the common case. SSH 1 protocol support is disabled by default.
</ul>
![[BACK]](/icons/back.gif){kind=icon}
Return to security.html CVS log ![[TXT]](/icons/text.gif){kind=icon}
![[DIR]](/icons/dir.gif){kind=icon}
Up to [local] / www / openssh