SSH Communications Security
Japanese site | Sitemap
Purchase Download Contact
Company
Sales About SSH Careers Contact Information News Room Public Relations Events
News Room

News Room



Helsinki, Finland - November 25, 2002

SSH Secure Shell Unix server setsid() function call vulnerability (VU#740619)

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.5

Customers 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.2

If 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.

AIX
HP-UX
Linux
Solaris

Non-commercial users

Only 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.

> More news from year 2002 > Archives: 2002 | 2001 | 2000 | 1999 | 1998
© 2002 SSH Communications Security Corp. All rights reserved. ssh® is a registered trademark of SSH Communications Security Corp in the United States and in certain other jurisdictions. All other names and marks are property of their respective owners.