Exploitation of vulnerability in SSH1 CRC-32 compensation attack detectorOriginal release Date: November 5, 2001
Last revised: November 7, 2001
The CERT/CC has received multiple reports of systems being compromised via the CRC-32 compensation attack detector vulnerability described in VU#945216. We are also receiving reports of increased scanning activity for the SSH service (22/tcp).
In reports received by the CERT/CC, systems compromised via this vulnerablity have exhibited the following pattern in system log messages:
hostname sshd[xxx]: Disconnecting: Corrupted check bytes on input. hostname sshd[xxx]: Disconnecting: crc32 compensation attack: network attack detected hostname sshd[xxx]: Disconnecting: crc32 compensation attack: network attack detected ...
The exploit for this vulnerability appears to use a brute force method, so many messages of this type may be logged before a system is successfully compromised.
The following artifacts have been discovered on systems that were successfully compromised:
- Installation of rootkits that modify standard system utilities to hide the intruder's actions
- Installation of Trojan horse versions of the SSH software, compiled from the latest OpenSSH source code plus intruder-supplied modifications
- Installation of tools to scan large network blocks for other systems that are vulnerable to compromise. Log files left behind from these tools indicate that they operate by looking for the banner displayed upon connection to the sshd service.
III. ImpactAn intruder can execute arbitrary code with the privileges of the SSH daemon, typically root.
Apply a patchPlease refer to the vendor information contained in VU#945216 for information on available patches. In cases where patches are not available, the CERT/CC recommends upgrading to the latest version of the appropriate secure shell software package.
Disable SSHv1 fallback supportBecause the vulnerability affects software handling the SSHv1 protocol, sites may wish to enable SSHv2 support only and disable SSHv1 fallback support. Refer to your secure shell server software documentation for information about how to accomplish this.
Disabling SSHv1 support is generally a good practice, since a number of other vulnerabilities exist in the SSHv1 protocol itself and software handling of this protocol.
Restrict access to the secure shell service
Until a patch can be applied, you may wish to restrict access to the secure shell service. This can be accomplished by applying packet filters for port 22/tcp at your network perimeter. While this measure will limit your exposure to attacks, blocking port 22/tcp at a network perimeter would still allow attackers within the perimeter of your network to exploit the vulnerability. It is important to understand your network's configuration and service requirements before deciding what changes are appropriate.
In cases where applying packet filters is not feasible, host-based access control can be used. Some secure shell implementations support builtin access control by means of the AllowHosts directive in the SSH server configuration file. If this support is not available, software such as Wietse Venema's TCP Wrappers can be used to restrict access to the secure shell daemon.
If you believe a host under your control has been compromised, you may wish to refer to
Author(s): Roman Danyliw, Chad Dougherty, John Shaffer
CERT/CC Contact Information
CERT Coordination Center
Software Engineering Institute
Carnegie Mellon University
Pittsburgh PA 15213-3890
Phone: +1 412-268-7090 (24-hour hotline)
Fax: +1 412-268-6989
We strongly urge you to encrypt sensitive information sent by email. Our public PGP key is available from
Getting security informationCERT publications and other security information are available from our web site
email@example.com. Please include in the body of your message
* "CERT" and "CERT Coordination Center" are registered in the U.S. Patent and Trademark Office.
Any material furnished by Carnegie Mellon University and the Software Engineering Institute is furnished on an "as is" basis. Carnegie Mellon University makes no warranties of any kind, either expressed or implied as to any matter including, but not limited to, warranty of fitness for a particular purpose or merchantability, exclusivity or results obtained from use of the material. Carnegie Mellon University does not make any warranty of any kind with respect to freedom from patent, trademark, or copyright infringement.
Conditions for use, disclaimers, and sponsorship information
Copyright 2001 Carnegie Mellon University.
November 5, 2001: Initial Release November 7, 2001: Avoid confusion between commercial product and general terms