A security concern has been identified with the SSH protocol and it affects our products unless mitigated via configuration. The affected products are PrivX, Tectia client/server, Universal Key Manager, and NQX. Tectia z/OS and SSH Secure Collaboration (formerly Deltagon) are not affected.
We’re releasing instructions on how to mitigate the issue via product configuration and will be releasing remediated versions of the products as point releases or as part of the normal release process and release cadence.
If you have any questions or concerns, please contact your SSH representative.
Security and reliability are paramount to SSH, as they are to our customers and partners. We are committed to ensuring that our products are safe and reliable.
The Terrapin attack is a medium-impact security vulnerability in the SSH protocol. Terrapin allows attackers to manipulate sequence numbers during the protocol handshake phase. This manipulation can lead to truncation of messages without detection, compromising the integrity of the secure channel.
Terrapin only affects the SSH protocol.
Users and servers are susceptible to the Terrapin attack during the SSH handshake phase, specifically when using vulnerable encryption modes like ChaCha20-Poly1305 or CBC with Encrypt-then-MAC. A crucial aspect of this attack is the need for an attacker to have a Man-in-the-Middle (MitM) position or a TCP/IP interceptor component to manipulate sequence numbers for message truncation.
Attacks utilizing the Terrapin vulnerability threaten the early secure channel's integrity before server and user authentication in affected SSH sessions.
A successful attack allows an attacker to control the availability of certain additional security features of the SSH session - such as supported-signature-algorithms for user RSA authentication keys. Failed attacks will cause targeted SSH sessions to freeze, as the authentication protocol does not start due to malformed requests. The active MITM can cause a similar effect without Terrapin just by blackholing the session.
On SSH Communications Security products, a Terrapin-related attack does not allow server impersonation or unauthenticated user access. It does not have an impact on transferred data confidentiality or integrity either.
Fully closing the attack vector while keeping vulnerable cipher suites requires an update of both client and server software to versions implementing OpenSSH strict key exchange extension.
We recommend that you mitigate the vulnerability by disabling the affected cipher suites from our products and updating the product when a remediated version is available. Please note that it is advisable to keep the affected cipher suites disabled even after individual products have been updated unless it can be ensured that there are no vulnerable products (products that do not implement strict KEX) in the infrastructure from SSH or from other vendors.
See product-specific mitigation instructions below.
PrivX is affected if configured to use the following algorithms (see /opt/privx/etc/ssh-algorithms.toml):
sshtarget.ciphers is empty, or
sshtarget.ciphers contains chacha20-poly1305@openssh.com, or
sshtarget.ciphers contains aes128-cbc or 3des-cbc and sshtarget.macs contains any *-etm@openssh.com algorithm
sshclient.ciphers is empty, or
sshclient.ciphers contains chacha20-poly1305@openssh.com, or
sshclient.ciphers contains aes128-cbc or 3des-cbc and sshclient.macs contains any *-etm@openssh.com algorith
Affected connection types are:
For the first four connections, the attacker needs MITM (Man-in-the-Middle) access to networks between PrivX and the target resource. For the last listed connection, the attacker needs access to the network between the user workstation and the PrivX bastion.
PrivX versions 30.2, 31.1 and 32.1 and older default configuration uses the affected algorithms.
Configure the default cipher and mac algorithms in /opt/privx/etc/ssh-algorithms.toml:
Restart PrivX.
Note that this may result in SSH handshake failures with old SSH servers and clients.
The vulnerability is fixed in versions 30.3, 31.2, and 32.2.
The fix includes the following changes:
It is possible to revert to using the vulnerable algorithm combinations by editing the /opt/privx/etc/ssh-algorithms.toml file. This is not recommended unless it is certain that all target servers and clients, that PrivX communicates with, support the OpenSSH strict KEX protocol extension.
Tectia is affected if configured to use any of the following algorithms:
*-CBC in Ciphers with any *-etm@openssh.com in MAC algorithms
By default, Tectia uses only CTR and GCM mode since version 6.6.3 and CTR mode since version 6.5.1. The default order of MACs uses EtM algorithms only if their normal non-EtM counterparts are not enabled by the client.
Tectia versions 6.4.18-6.4.20 have affected CBC algorithms enabled with *-etm@openssh.com MAC algorithms. Customers who have not verified the algorithm lists after upgrading to newer versions should review the mitigation steps.
Tectia z/OS is not affected.
When you upgrade from a version prior to Tectia 6.5.1, please verify that ssh-server-config.xml and ssh-broker-config.xml do not have CBC ciphers enabled.
The algorithms can be disabled by removing the following algorithms from ssh-server-config.xml and ssh-broker-config.xml.
In Ciphers, it has already been strongly recommended not to use the below-mentioned CBC ciphers:
In MACs:
The vulnerability is fixed in version 6.6.3. The fix includes the following changes:
It is possible to revert to using the vulnerable algorithm combinations in ssh-server-config.xml and ssh-broker-config.xml. This is not recommended unless it is certain that all clients/servers support the strict KEX protocol extension.
UKM uses OpenSSH to connect to managed hosts. UKM is affected in the default configuration. All currently supported versions (3.4, 4.0, 4.1, 4.2, 4.3, and 5.0) are affected.
UKM also optionally uses a Tectia Server product to receive incoming connections from agents on managed hosts. If this feature is in use, the section for mitigation and remediation for the Tectia Server should be followed as well.
The vulnerability will be fixed in version 5.1, release date by the end of 2023.
SSH Secure Collaboration 2024 products are not directly affected, and the customer tenant instances will get updated OpenSSH with the system updates.
The remote access to NQX nodes is not affected by the vulnerability because the SSH server configuration does not include vulnerable cipher suites.
In case the NQX node is used as an SSH client to connect to another instance, the vulnerable cipher suite is used. For example, having an SSH connection from one node to another. The impact is limited, as there is no need to use this functionality to operate NQX. All the NQX operations can be done via Local Manager (LM) and Central Manager (CM) which are not impacted.
In case the SSH client is used from the NQX node, the mitigation is to apply a user-specific SSH client configuration file ~sshfw/.ssh/config. The following shell command run as sshfw-user will perform the necessary configuration change:
$ cat << EOD > ~sshfw/.ssh/config
Ciphers -chacha20-poly1305@openssh.com,*-cbc*
MACs -*-etm@openssh.com
EOD
