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.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Paranoid Penguin - Building a Secure Squid Web Proxy, Part IV
- SUSE LLC's SUSE Manager
- Google's SwiftShader Released
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- SuperTuxKart 0.9.2 Released
- Parsing an RSS News Feed with a Bash Script
- Rogue Wave Software's Zend Server
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide