OpenSSH Remote Vulnerability Roundup
In a recent discussion about the Apache Chunk Handling vulnerability, which consisted of many debates and rants on how the reporting was done, ISS mentioned that they found another serious vulnerability in one other vendor’s open source product. First post about this vulnerability is presented below the ISS advisory released today.
Internet Security Systems Security Advisory
OpenSSH Remote Challenge Vulnerability
ISS X-Force has discovered a serious vulnerability in the default installation of OpenSSH on the OpenBSD operating system. OpenSSH is a free version of the SSH (Secure Shell) communications suite and is used as a secure replacement for protocols such as Telnet, Rlogin, Rsh, and Ftp. OpenSSH employs end-to-end encryption (including all passwords) and is resistant to network monitoring, eavesdropping, and connection hijacking attacks. X-Force is aware of active exploit development for this vulnerability.
Advisory:
Theo de Raadt from OpenBSD and OpenSSH development team shed some light and announced that OpenSSH is vulnerable. This is his post to BugTraq mailing list:
There is an upcoming OpenSSH vulnerability that we’re working on with ISS. Details will be published early next week.
However, I can say that when OpenSSH’s sshd(8) is running with priv seperation, the bug cannot be exploited.
OpenSSH 3.3p was released a few days ago, with various improvements but in particular, it significantly improves the Linux and Solaris support for priv sep. However, it is not yet perfect. Compression is disabled on some systems, and the many varieties of PAM are causing major headaches.
However, everyone should update to OpenSSH 3.3 immediately, and enable priv seperation in their ssh daemons, by setting this in your /etc/ssh/sshd_config file:
UsePrivilegeSeparation yes
Depending on what your system is, privsep may break some ssh functionality. However, with privsep turned on, you are immune from at least one remote hole. Understand?
3.3 does not contain a fix for this upcoming bug.
If priv seperation does not work on your operating system, you need to work with your vendor so that we get patches to make it work on your system. Our developers are swamped enough without trying to support the myriad of PAM and other issues which exist in various systems. You must call on your vendors to help us.
Basically, OpenSSH sshd(8) is something like 27000 lines of code. A lot of that runs as root. But when UsePrivilegeSeparation is enabled, the daemon splits into two parts. A part containing about 2500 lines of code remains as root, and the rest of the code is shoved into a chroot-jail without any privs. This makes the daemon less vulnerable to attack.
We’ve been trying to warn vendors about 3.3 and the need for privsep, but they really have not heeded our call for assistance. They have basically ignored us. Some, like Alan Cox, even went further stating that privsep was not being worked on because “Nobody provided any info which proves the problem, and many people dont trust you theo” and suggested I “might be feeding everyone a trojan” (I think I’ll publish that letter — it is just so funny). HP’s representative was
downright rude, but that is OK because Compaq is retiring him. Except for Solar Designer, I think none of them has helped the OpenSSH portable developers make privsep work better on their systems. Apparently Solar Designer is the only person who understands the need for this stuff.
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).
Neither S/Key or BSDAUTH were enabled in previous RPMs released by SuSE (i.e. the OpenSSH 2.9.9p2 RPMs previously released on March 6, and the OpenSSH 3.0.2p1 RPMs released with SuSE Linux 8.0). Support for interactive keyboard mode is compiled in, and is off by default in recent RPMs. However, it can be enabled by the administrator.
Which means that, in the default configuration, SuSE Linux users are not affected by this vulnerability.
We will release another set of RPMs that fix this vulnerability soon.
03.07.2002 – OpenSSH kbd-interactive Buffer Overflow
by Global InterSec Research
Advisory:
It is the current belief of many that exploiting the recently disclosed vulnerabilities in OpenSSH’s challenge-response routines is reliant upon a system’s use of BSD’s authentication mechanisms and therefore restricts the platforms on which this vulnerability may be exploited.
This is almost certainly due to various advisories posted to various fora by unnamed security companies.
Although it is widely known that all systems running versions of OpenSSH prior to 3.4 are affected by this vulnerability, many vendors have deemed their platforms invulnerable to exploitation.
In spite of this, our research has proven multiple platforms originally thought to be invulnerable to attack to be vulnerable.
Few vendors released security advisories that deal with this problem:
EnGarde Secure Linux Advisory – openssh introduce privilege separation into sshd
SuSE Security Announcement – openssh
SuSE Security Announcement – openssh (update)
Conectiva Linux Security Advisory – openssh
Debian Security Advisory – ssh
Debian Security Advisory – ssh (update 1)
Debian Security Advisory – ssh (update 2)
Debian Security Advisory – ssh (update 3)
Mandrake Linux Security Advisory – openssh
Mandrake Linux Security Advisory – openssh (update)
Conectiva Linux Security Advisory – openssh
Trustix Security Advisory – openssh
Caldera Security Advisory – OpenSSH Vulnerabilities in Challenge Response Handling
Red Hat Security Advisory – Updated OpenSSH packages fix various security issues
NetBSD Security Advisory – OpenSSH protocol version 2 challenge-response authentication vulnerability
CERT Advisory CA-2002-18 – OpenSSH Vulnerabilities in Challenge Response
Cisco Security Advisory – Scanning for SSH Can Cause a Crash
Revised OpenSSH Security Advisory
http://www.openssh.org/txt/preauth.adv
EnGarde Secure Linux Advisory – several vulnerabilities in the OpenSSH daemon
Compaq Security Bulletin – HP Tru64 UNIX V5.1a – SSH V1.1 & OpenSSH Challenge Response Handling, Potential Security Vulnerability
Sun statement on the OpenSSH Remote Challenge Vulnerability
An official Security bulletin with be released very soon but the following is an interim statement since we have received a number of enquiries. The version of OpenSSH that is in Solaris 9 is not beleived to be vulnerable if the default configuration is used. If sshd_config(4) has been updated so that BOTH of the following entries are present then it is vulnerable.
OpenSSH team strongly encourages users to upgrade immediately to OpenSSH 3.3 with the UsePrivilegeSeparation option enabled. Privilege Separation blocks this problem. Keep an eye out for the upcoming OpenSSH 3.4 release on Monday that fixes the vulnerability itself.
OpenSSH 3.4 released on June 26, 2002
Christophe Devine send a message to BugTraq titled: “OpenBSD 3.1 sshd remote root exploit” which can be read on the Neohapsis archives:
Privilege Separated OpenSSH model (text and image courtesy of Niels Provos):
We use an unprivileged child process to contain and restrict the effects of programming errors. A bug in the unprivileged child process does not result in a system compromise. In other words, the goal is complete privilege separation within in OpenSSH.
Privilege separation uses two processes: The privileged parent process that monitors the progress of the unprivileged child process. The child process is unprivileged. This is achieved by changing its uid/gid to an unused user and restricting its file system access via chroot() to /var/empty. It is the only process that processes network data. The privileged parent can be modelled by a very small finite-state machine so that it is easy to reason about the code that is being executed with privileges.
A well defined interface between privileged parent and unprivileged child allows the child to delegate operations that require privileges to the parent. Successful authentication is determined by the parent process.
Communication between the privileged and the unprivileged process is achieved by pipes. Shared memory stores state that can not be otherwise exported. The child has to ask the privileged parent to determine if authentication was successful or not.
If the child process gets corrupted and believes that the remote user has been authenticated, access will not be granted unless the parent has reached the same decision.
More information: http://www.citi.umich.edu/u/provos/ssh/privsep.html