Security Advisory regarding Unix server vulnerability in SSH Secure Shell for Servers & SSH Secure Shell for Workstations products, versions 2.0.13 to 3.2.1
Setsid() issue is a security issue on Unix systems. Non-interactive Secure Shell sessions (e.g., as used in scripts) pose a theoretical threat. There is the possibility of an attacker obtaining administrator privileges on NetBSD variants, although no successful exploits have been established.
An actual exploit where log entries are forged does exist.
Affected Systems
SSH Secure Shell for Servers and SSH Secure Shell for Workstations, versions 2.0.13 - 3.2.1. The vulnerability affects all POSIX Unixes (AIX, Linux, HP-UX, Solaris, any BSD).
Description of the Vulnerability
When used in non-interactive connections, a defect in process grouping of SSH Secure Shell processes may allow malicious activity. If executing a command without a pty (including running commands and subsystems) the child process remains in the process group of the master process.
On platforms relying on getlogin() (mainly the different BSD variants) malicious users can at least send misleading messages to syslog and others applications (getlogin() call will return "root").
Risk of Exploit
No root privilege exploits are known at this time, but they may be possible (for example, if a setuid-application relies on the output of getlogin()).
This vulnerability allows for setting the login name to for example "root". Applications that trust the login name and do not check the user ID or effective user ID are vulnerable to user identity spoofing. For example false log entries can be produced on BSD systems.
A limitation to the possible exploitations of this vulnerability is that the malicious user needs to have access to some user account on the system to be able to exploit this vulnerability.
Description of the fix
In SSH Secure Shell 3.1.5 and 3.2.2 the setsid() function is called for every forked child process which will run on the user's privileges. Previously, setsid() was called only if there was a pty/tty.
Solution to the problem
Update or upgrade to SSH Secure Shell version 3.1.5 or 3.2.2 that contains the fix for this vulnerability.
Customers may download the SSH Secure Shell update from the http links listed below. A valid license_ssh2.dat is required for all the binaries. Depending on your license file the Unix binaries will function as SSH Secure Shell for Workstations or SSH Secure Shell for Servers product.
Updating SSH Secure Shell from 3.1.x to 3.1.5Customers entitled to version 3.1 who submitted their email address to the SSH Communications Security sales department were provided a link to download appropriate license file. Please contact your sales representative if you wish to obtain the license file.
AIX HP-UX Linux Solaris Updating SSH Secure Shell from 3.2.x to 3.2.2If you have a commercial license for a 3.2.x product, you can install the 3.2.2 version binaries on top of the old 3.2.x ones.
AIXHP-UX LinuxSolarisNon-commercial usersOnly non-commercial source code and English Windows client binary without PKI and smart card functionality are available for the non-commercial users. No license.dat file is required for the non-commercial versions available at
ftp://ftp.ssh.com/pub/ssh/Please see the list of available
mirror sites.
Credits
Special thanks to Logan Gabriel for finding this issue.
SSH Communications Security Corp is committed to utmost security
SSH Communications Security apologizes for any inconvenience caused. We take security of the systems of our customers very seriously and do our utmost to provide secure software. We strongly urge all customers to consider the implications of this vulnerability carefully and to make an educated decision on whether or not to update/upgrade.