OpenSSH Remote Vulnerability Roundup
by Berislav Kucan - updated on 3 July 2002 with: Compaq Security Bulletin, revised Mandrake Linux and SuSE Linux advisories, new EnGarde Secure Linux advisory and OpenSSH kbd-interactive Buffer Overflow
So, if vendors would JUMP and get it working better, and send us patches IMMEDIATELY, we can perhaps make a 3.3.1p release on Friday which supports these systems better. So send patches by Thursday night please. Then on Tuesday or Wednesday the complete bug report with patches (and exploits soon after I am sure) will hit BUGTRAQ.

Let me repeat: even if the bug exists in a privsep'd sshd, it is not exploitable. Clearly we cannot yet publish what the bug is, or provide anyone with the real patch, but we can try to get maximum deployement of privsep, and therefore make it hurt less when the problem is published.

So please push your vendor to get us maximally working privsep patches as soon as possible!

We've given most vendors since Friday last week until Thursday to get privsep working well for you so that when the announcement comes out next week their customers are immunized. That is nearly a full week (but they have already wasted a weekend and a Monday). Really I think this is the best we can hope to do (this thing will eventually leak, at which point the details will be published).

Customers can judge their vendors by how they respond to this issue.

OpenBSD and NetBSD users should also update to OpenSSH 3.3 right away. On OpenBSD privsep works flawlessly, and I have reports that is also true on NetBSD. All other systems appear to have minor or major weaknesses when this code is running.



Olaf Kirch from SuSE Security team noted the following on suse-security-announce mailing list:

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 from SuSE Security team noted the following on suse-security-announce mailing list:

ISS and the OpenSSH team just released advisories concerning the OpenSSH vulnerability. These advisories state that the vulnerability exists only if the package has been compiled with support for S/Key or BSDAUTH authentication. Inspecting the patches included in the OpenSSH advisory however show that there is a second vulnerability that can be exploited when interactive keyboard mode is enabled (via the PAMAuthenticationViaKbdInt option in sshd_config).

Spotlight

USBdriveby: Compromising computers with a $20 microcontroller

Posted on 19 December 2014.  |  Security researcher Samy Kamkar has devised a fast and easy way to compromise an unlocked computer and open a backdoor on it: a simple and cheap ($20) pre-programmed Teensy microcontroller.


Weekly newsletter

Reading our newsletter every Monday will keep you up-to-date with security news.
  



Daily digest

Receive a daily digest of the latest security news.
  
DON'T
MISS

Fri, Dec 19th
    COPYRIGHT 1998-2014 BY HELP NET SECURITY.   // READ OUR PRIVACY POLICY // ABOUT US // ADVERTISE //