Portable OpenSSH Security Advisory: sshpam.adv
Please see below for details of another openssh advisory. Is the current patched version of SuSE vulnerable to this attack? The advisory warns that we are vulnerable if privsep is disabled - the most recent patch from SuSE disabled privsep by default! I like the idea of privsep, please can somebody at SuSE answer the following: 1. How do I re-enable privsep - is it enough to turn it on in the sshd_config? 2. What is the problem with enabling privsep in the latest release? 3. How do I check that privsep is actually working - there doesn't seem to be any record of it in the syslog. 4. I am used to restricting access to many services via the hosts.allow - will this help if there is an sshd exploit? Thanks -- Simon Oliver This document can be found at: http://www.openssh.com/txt/sshpam.adv 1. Versions affected: Portable OpenSSH versions 3.7p1 and 3.7.1p1 contain multiple vulnerabilities in the new PAM code. At least one of these bugs is remotely exploitable (under a non-standard configuration, with privsep disabled). The OpenBSD releases of OpenSSH do not contain this code and are not vulnerable. Older versions of portable OpenSSH are not vulnerable. 2. Solution: Upgrade to Portable OpenSSH 3.7.1p2 or disable PAM support ("UsePam no" in sshd_config). Due to complexity, inconsistencies in the specification and differences between vendors' PAM implementations we recommend that PAM be left disabled in sshd_config unless there is a need for its use. Sites only using public key or simple password authentication usually have little need to enable PAM support.
Please see below for details of another openssh advisory.
Is the current patched version of SuSE vulnerable to this attack?
No, because that versions (2 versions) is not used in any SuSE product.
The advisory warns that we are vulnerable if privsep is disabled - the most recent patch from SuSE disabled privsep by default!
I like the idea of privsep, please can somebody at SuSE answer the following:
1. How do I re-enable privsep - is it enough to turn it on in the sshd_config?
Yes, and restarting/reloading the sshd process.
2. What is the problem with enabling privsep in the latest release?
Calling PAM routines is not suitable if not running as root. It just doesn't work.
3. How do I check that privsep is actually working - there doesn't seem to be any record of it in the syslog.
Look at the processes while you are logged on via ssh. You should be able to see that the sshd uses another uid.
4. I am used to restricting access to many services via the hosts.allow - will this help if there is an sshd exploit?
Yes. That's a sign for experience if you're using tcp_wrappers. Independently from hosts.allow, access can be restricted in sshd_config, too.
Thanks Simon Oliver
You're welcome. Roman.
Calling PAM routines is not suitable if not running as root. It just doesn't work. So the PAMAuthenticationViaKbdInt will not work?
Independently from hosts.allow, access can be restricted in sshd_config, Is that via the AllowUsers option? Would this help protect against the current security vulnerabilities? I ask, because I have some machines that are running an older sshd that does not have privsep and is not compiled with libwrap support.
Thanks for your advice -- Simon Oliver
Hi !
Independently from hosts.allow, access can be restricted in sshd_config, Is that via the AllowUsers option? Would this help protect against the current security vulnerabilities?
--> There is also a "Hosts" directive to restrict logins to specific IP addresses. It definitely helps you to restrict the number of IPs and users that can connect, but it does not really protect you against the security vulnerability. Because if someone connects from an allowed IP with an allowed user name, he can exploit the vulnerability. But of course chances for this are much smaller than if everybody can try. Bye, Armin -- Am Hasenberg 26 office: Institut für Atmosphärenphysik D-18209 Bad Doberan Schloss-Straße 6 Tel. ++49-(0)38203/42137 D-18225 Kühlungsborn / GERMANY Email: schoech@iap-kborn.de Tel. +49-(0)38293-68-102 WWW: http://armins.cjb.net/ Fax. +49-(0)38293-68-50
--> There is also a "Hosts" directive to restrict logins to specific IP addresses. It is not documented and when I tried it (on a box running OpenSSH_3.4p1) sshd start failed, complaining about the Hosts directive (perhaps I formatted it incorrectly).
I did get it working with the AllowUsers directive: AllowUsers *@*.my.domain Using this method I find that it still gives the user a login prompt (but always rejects their login unless they are within *.my.domain). Assuming I can trust all machines in *.my.domain, will this actually protect from the vulnerability? At what point in the connection process does the exploit occur - presumably prior to login? -- Simon Oliver
Hi !
--> There is also a "Hosts" directive to restrict logins to specific IP addresses. It is not documented and when I tried it (on a box running OpenSSH_3.4p1) sshd start failed, complaining about the Hosts directive (perhaps I formatted it incorrectly).
--> Sorry for that wrong hint. I googled a little and found only what you did:
I did get it working with the AllowUsers directive: AllowUsers *@*.my.domain
Bye, Armin
openssh can be compiled with tcp-wrappers support and then an entry put in /etc/hosts.allow like sshd: 192.168.1. : ALLOW compile openssh with the following option ./configure --with -tcp-wrappers On Wednesday 24 September 2003 08:56, Simon Oliver wrote:
--> There is also a "Hosts" directive to restrict logins to specific IP addresses.
It is not documented and when I tried it (on a box running OpenSSH_3.4p1) sshd start failed, complaining about the Hosts directive (perhaps I formatted it incorrectly).
I did get it working with the AllowUsers directive:
AllowUsers *@*.my.domain
Using this method I find that it still gives the user a login prompt (but always rejects their login unless they are within *.my.domain). Assuming I can trust all machines in *.my.domain, will this actually protect from the vulnerability? At what point in the connection process does the exploit occur - presumably prior to login?
-- Simon Oliver
-- Chad Whitten Network/Systems Administrator neXband Communications cwhitten@nexband.com
participants (4)
-
Armin Schoech -
Chad Whitten -
Roman Drahtmueller -
Simon Oliver