A Rough Year for SSH
This vulnerability in SSH1 is probably the biggest threat to a typical ssh server on the network today, and is, at the time of this writing, in active abuse by hackers. This is related to the classic buffer overflow attack, and gives an attacker root access to the compromised machine.
In 1998, CORE-SDI, a South American security firm, noticed a subtle attack on the encryption used by Ssh. By abusing the checksum routine, which uses the CRC32 algorithm, an attacker can begin a plaintext attack on the payload of the ssh session. To counter this attack, a compensator was included in ssh. When it is tripped, a log message is generated.
In early 2001, Michal Zalewski of the Razor team at Bindview noticed a memory allocation error in the compensator. Briefly, only 16 bits of data were allocated to store a 32-bit value. By carefully crafting an attack as discussed by CORE-SDI, this table index can be overflowed and arbitrary code executed on the server with full root privileges. At the time of the discovery, no known working exploits were available. However, since then an exploit has begun circulating in ever increasing circles. This attack is under heavy abuse by some hackers as 2001 draws to a close. There is even some evidence that a worm has been developed using this attack vector.
Due to the nature of the vulnerability, this issue was addressed immediately by both the Ssh developers and the OpenSSH team. Since Ssh version 1.2.32 and OpenSSH version 2.3.0, this issue has been fixed. All ssh users should have upgraded as this is being actively exploited.
Late in 2001 a minor bug was found in OpenSSH when the UseLogin directive is employed. Simply put, before any privileges were dropped (the daemon runs as root), the environment of the user was processed. This allowed an attacker to craft their LD_PRELOAD, for example, to include a malicious library call that elevated their privileges.
A valid local account is required to execute this vulnerability, and a working example of how to do this has been posted to public lists for security matters. Note that UseLogin is not enabled by default, and this has been fixed in OpenSSH 3.0.2.
A few small issues have been brought to light this past year, as well, concerning the security of ssh. They've been fixed, but definitely are worth pointing out.
First, a recent problem in Ssh version 3.0.0 was found. Accounts which had been locked with a password field of only two characters, no more, no less, could be entered without any validation of any kind. On some commercial UNIX platforms with multiple UID 0 accounts locked by this mechanism, a serious security breech could be encountered. This was fixed in Ssh 3.0.1.
IP address based access control was an issue in OpenSSH 2.9 and earlier versions, allowing an attacker to bypass connection restrictions. This occurred under rare circumstances in a particularly formatted authorized key file using the "from=" directive for access control. This was fixed in OpenSSH 2.9.9, and doesn't affect many users.
Resource starvation attacks, where an adversary attempts to flood the server with connection requests, are also mitigated in OpenSSH. A parameter exists to configure the daemon to control the number of children it spawns, helping to prevent this sort of attack. Ssh 1.2.x is still vulnerable, though.
This has been a dizzying year for ssh users attempting to maintain their secure systems and networks. By far the biggest reason to upgrade an ssh installation is the CRC32 compensator attack, which is in growing abuse around the world. Vendors have released updated binaries and packages, ensuring that their systems can be made secure against this attack vector.
Obviously some of these attacks are more theoretical or academic, and shouldn't cause much alarm in ssh administrators. Most sites will not have the information leaked in the passive traffic analysis attack, using the Herbivoir tool, cause them much harm. Sites that are concerned about this, such as those with government secrets, should be relying on more secure mechanisms anyhow to protect their traffic.
The local privileges escalation attack outlined above should also be minded, and the site adjusted accordingly. Either turn off the UseLogin directive or, if that option is unavailable, ensure that your site is updated to the latest version of OpenSSH. The attack doesn't require much sophistication on the part of the interested party.
For these reasons, the following basic recommendation are made to ssh administrators. Use SSH2, rather than SSH1. Clients are available for SSH2 now with widespread availability, including for Mac and Windows, and many of these clients are freely available. Things have changed significantly on this front in the past year. OpenSSH supports both protocols SSH1 and SSH2 in a single binary, with a simple directive in the server determining the order in which they are attempted.
Secondly, encourage your users to use public key authentication. Several great tutorials have been written on the subject, and its rather easy to set up. This will help stem attacks on the passwords for your users, making such an attack much harder to mount.
Thirdly, keep in mind that even though ssh can perform strong authentication, not every attacker needs to authenticate to gain control of their target. With this in mind, it is wise to use a firewall or some other means to control login access to the ssh server.
Lastly, don't allow root logins via ssh directly, instead force users to login as a regular user and use "su" to root. This will help stem several attacks before they can even begin.
Obviously, staying up to date is the best method to protect your servers. Together with a sound configuration evaluation, ssh can enhance security, not compromise your site's risk profile. Because of the increased usage of ssh in nonstandard devices, such as IOS on Cisco routers, upgrading totally to eliminate the problems with faulty ssh implementations may not be totally possible. However, keep an eye out for your vendor's updates.
Currently, both major forms of ssh allow for even greater authentication mechanisms. OpenSSH has added support for smart card authentication, which can be useful for sites using token based authentication mechanisms. SSH2 allows for PGP keys to be used to authenticate against a server, enabling a web of trust in the authentication of users employing public key authentication schemes. Lastly, Ssh 3.0 adds support for a PKI in the server keys, ensuring trust relationships for the keys and helping to stem off the man-in-the-middle type attacks through verification of the keys presented to the client. All versions of ssh, both Ssh and OpenSSH, also support Kerberos authentication and S/Key and One Time Pad passwords. On Linux, the use of PAM extends this to even more mechanisms through the PAM interface. These authentication mechanisms have matured, and their interest has grown, as a result of the attacks on the authentication mechanisms from this past year.
In conclusion, ssh has been the focus of a significant amount of scrutiny this past year, and through it the product and protocol have improved. By raising awareness to the security issues, as well as providing a robust, open-source alternative in OpenSSH, the ssh community has improved the state of internet security. Administrators and users should keep up to date with their ssh software to ensure their security.
One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems
Join editor Bill Childers and Bit9's Paul Riegle on April 27 at 12pm Central to learn how to keep your Linux systems secure.
Free to Linux Journal readers.Register Now!
- Python Scripts as a Replacement for Bash Utility Scripts
- Considering Legacy UNIX/Linux Issues
- [<Megashare>] Watch Mrs Brown's Boys Movie Online Full Movie HD 2014
- Cluetrain at Fifteen
- Memory Ordering in Modern Microprocessors, Part I
- New Products
- Getting Good Vibrations with Linux
- RSS Feeds
- Security Hardening with Ansible
- diff -u: What's New in Kernel Development