Vulnerability Note VU#25309
Weak CRC allows RC4 encrypted SSH1 packets to be modified without notice
There is an information integrity vulnerability in the SSH1 protocol that allows RC4 encrypted packets to be modified without notice.
Client has requested RC4 and server supports it.
Compression is disabled.
When using the RC4 stream cipher, SSH1 uses a cyclic redundancy check (CRC) algorithm to perform an integrity check on incoming packets. Because the CRC checksum can be modified, an attacker can intercept an SSH packet, modify its contents, then modify the CRC to match. When the packet is then retransmitted from the attacker to the victim, the CRC integrity check will pass. This means that the attacker can make arbitrary modifications to the packet and the victim will be unable to detect them. This vulnerability results from the fact that CRC is not intended for cryptographic integrity checks. As a result, the CRC algorithm does not contain any security measures to prevent tampering with the checksum.
To exploit this vulnerability, an attacker must:
- Take a SSH packet of the form P | C, where P is the packet data and C is the CRC checksum for that packet.
- Create a mask M, which contains the bits in P that you want to toggle.
- Calculate the CRC for M and call it C'.
- Use XOR to create the following packet: P XOR M | C XOR C'
- Send the modified packet to the victim in place of the original packet.
Because the CRC has been modified to account for the "addition" of M, the CRC integrity check on the victim's SSH client will pass.
Attackers can modify or logically delete arbitrary SSH packets.
SSH Secure Communications recommends disabling RC4 in SSH1 or upgrading to SSH2.
If you are a vendor and your product is affected, let
|Vendor||Status||Date Notified||Date Updated|
|SSH Communications Security||Affected||-||06 Feb 2001|
|OpenSSH||Not Affected||-||29 Oct 2001|
The CERT/CC thanks Antti Huima, Tuomas Aura, and Janne Salmi for their analysis and Tatu Ylonen for bringing this vulnerability to our attention.
This document was written by Jeffrey P. Lanza.
18 Jan 2001
Date First Published:
18 Jan 2001
Date Last Updated:
05 Mar 2002
If you have feedback, comments, or additional information about this vulnerability, please send us email.