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.
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
|Non-Linux FOSS: Seashore||May 10, 2013|
- Dynamic DNS—an Object Lesson in Problem Solving
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Using Salt Stack and Vagrant for Drupal Development
- New Products
- A Topic for Discussion - Open Source Feature-Richness?
- Drupal Is a Framework: Why Everyone Needs to Understand This
- Validate an E-Mail Address with PHP, the Right Way
- RSS Feeds
- Readers' Choice Awards
- Tech Tip: Really Simple HTTP Server with Python
2 hours 4 min ago
- Reply to comment | Linux Journal
2 hours 36 min ago
- All the articles you talked
5 hours 5 sec ago
- All the articles you talked
5 hours 3 min ago
- All the articles you talked
5 hours 4 min ago
9 hours 29 min ago
- Keeping track of IP address
11 hours 20 min ago
- Roll your own dynamic dns
16 hours 33 min ago
- Please correct the URL for Salt Stack's web site
19 hours 45 min ago
- Android is Linux -- why no better inter-operation
22 hours 28 sec ago
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi
It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Pi Cobbler Breakout Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?