Date: Tue, 25 Jun 2002 10:39:34 +0200
From: Olaf Kirch <okir@suse.de>
To: suse-security-announce@suse.com
Subject: [suse-security-announce] OpenSSH Vulnerability


There's a new vulnerabiltiy in the OpenSSH daemon. The OpenSSH/OpenBSD
team does not release any details concerning this issue, except:

 -      This bug still exists in the most recent version, 3.3

 -      They are asking all users to upgrade to version 3.3 (sic),
 	and enable the PrivilegeSeparation option.

Setting PrivilegeSeparation to on causes large portions of the daemon
to run in a so-called "chroot jail", i.e. in a very restricted environment.
An attacker breaking this part of the SSH daemon will *not* obtain full
root privilege (as he would if sshd runs without this option), but
will find himself in an empty directory, inside a process running as
a non privileged user (he can still do some harm this way, but it's
a far cry from full root powers, of course).

In a posting to bugtraq, Theo de Raadt says that using privilege
separation, this new vulnerability cannot be exploited.

The SuSE security team is working on creating OpenSSH updates with
privilege separation enabled, and testing this functionality. We
will release updated RPMs on FTP as they become available.

In the meanwhile, we suggest that

 -	if you do not need external access to your SSH daemons,
 	turn off the SSH service on these machine completely,
	or block external access at the firewall.

 -	if you do need extern access to your SSH daemons,
 	make sure you restrict the hosts that it will talk to
	by setting appropriate firewall rules.

	If, for some reason, you cannot configure your firewall to
	block external SSH access, you can also restrict access through
	/etc/hosts.allow; the following will allow connections from
	hosts with IP addresses 1.2.3.4 and 5.6.7.8 while disallowing
	any other connections.

		sshd	: 1.2.3.4	: allow
		sshd	: 5.6.7.8	: allow
		sshd	: ALL		: deny

	It is not clear however whether this is really effective
	because we do not know anything about the vulnerability
	at all.

Olaf Kirch




SuSE: OpenSSH Advisory Update

June 25, 2002
Theo de Raadt announced that the OpenBSD team is working with ISSon a remote exploit for OpenSSH

Summary


Date: Tue, 25 Jun 2002 10:39:34 +0200
From: Olaf Kirch <okir@suse.de>
To: suse-security-announce@suse.com
Subject: [suse-security-announce] OpenSSH Vulnerability


There's a new vulnerabiltiy in the OpenSSH daemon. The OpenSSH/OpenBSD
team does not release any details concerning this issue, except:

 -      This bug still exists in the most recent version, 3.3

 -      They are asking all users to upgrade to version 3.3 (sic),
 	and enable the PrivilegeSeparation option.

Setting PrivilegeSeparation to on causes large portions of the daemon
to run in a so-called "chroot jail", i.e. in a very restricted environment.
An attacker breaking this part of the SSH daemon will *not* obtain full
root privilege (as he would if sshd runs without this option), but
will find himself in an empty directory, inside a process running as
a non privileged user (he can still do some harm this way, but it's
a far cry from full root powers, of course).

In a posting to bugtraq, Theo de Raadt says that using privilege
separation, this new vulnerability cannot be exploited.

The SuSE security team is working on creating OpenSSH updates with
privilege separation enabled, and testing this functionality. We
will release updated RPMs on FTP as they become available.

In the meanwhile, we suggest that

 -	if you do not need external access to your SSH daemons,
 	turn off the SSH service on these machine completely,
	or block external access at the firewall.

 -	if you do need extern access to your SSH daemons,
 	make sure you restrict the hosts that it will talk to
	by setting appropriate firewall rules.

	If, for some reason, you cannot configure your firewall to
	block external SSH access, you can also restrict access through
	/etc/hosts.allow; the following will allow connections from
	hosts with IP addresses 1.2.3.4 and 5.6.7.8 while disallowing
	any other connections.

		sshd	: 1.2.3.4	: allow
		sshd	: 5.6.7.8	: allow
		sshd	: ALL		: deny

	It is not clear however whether this is really effective
	because we do not know anything about the vulnerability
	at all.

Olaf Kirch




References

Severity

Related News