Sign Up for Your FREE Weekly SecurityTracker E-mail Alert Summary
Put SecurityTracker Vulnerability Alerts on Your Web Site -- It's Free!
Become a Partner and License Our Database or Notification Service
(Vendor Issues Statement) Unspecified Vulnerability is Reported in OpenSSH That May Allow Remote Users to Gain Root Access to the System
SecurityTracker Alert ID: 1004619|
SecurityTracker URL: http://securitytracker.com/id/1004619
(Links to External Site)
Date: Jun 25 2002
Execution of arbitrary code via network, Root access via network|
Vendor Confirmed: Yes |
Version(s): 2.3.1 - 3.3|
Two vulnerabilities were reported in the OpenSSH implementation of the Secure Shell SSH protocol. A remote user can obtain root access on the system in certain configurations.|
ISS originally reported that a buffer overflow vulnerability exists within the "challenge-response" authentication mechanism in the OpenSSH daemon (sshd). It has since been clarified that there are two separate but related vulnerabilities that occur in processing challenge responses.
One vulnerability is an integer overflow in the processing of the number of responses received during challenge response authentication. If the server is configured for challenge response authentication *and* the system is using SKEY or BSD_AUTH authentication, the system may be vulnerable. A remote user can send a specially-crafted reply to cause the daemon to crash or to execute arbitrary code with root privileges. This flaw is reported to be present in version 2.9.9 through 3.3.
The other vulnerability is a buffer overflow in the processing of the number of responses received during challenge response authentication. If the server is using using PAM modules that use interactive keyboard authentication (PAMAuthenticationViaKbdInt), the system may be vulnerable (however, this apparently has not been confirmed). This flaw is reported to be present in versoin 2.3.1 through 3.3.
A remote user can obtain root level access on the system, under certain system configurations.|
No solution was available at the time of this entry. Details are to be published 'early next week.'|
However, the vendor notes that with the new version (OpenSSH 3.3p), which does *not* correct the vulnerability, a user can run sshd(8) with 'priv separation' so that the bug 'cannot be exploited.'
The vendor recommends that everyone update to OpenSSH 3.3 immediately and enable priv seperation in their ssh daemons by setting the following configuration entry in the /etc/ssh/sshd_config file:
The vendor warns that, depending on the operating system, the 'privsep' feature may break some ssh functionality.
If priv seperation does not work on your operating system, the vendor recommends that users work with their operating system vendor to obtain patches.
See the Source Message for the vendor's full statement.
Vendor URL: www.openssh.org/ (Links to External Site)
Boundary error, Input validation error|
Linux (Any), UNIX (Any), Windows (Any)|
This archive entry is a follow-up to the message listed below.|
Source Message Contents
Date: Mon, 24 Jun 2002 15:28:12 -0600|
Subject: Upcoming OpenSSH vulnerability
Subject: Upcoming OpenSSH vulnerability
Date: Mon, 24 Jun 2002 15:00:10 -0600
From: Theo de Raadt <firstname.lastname@example.org>
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
However, everyone should update to OpenSSH 3.3 immediately, and enable
priv seperation in their ssh daemons, by setting this in your
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
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.
(securityfocus postmaster; please post this through immediately, since
i have bcc'd over 30 other places..)
------- End of Blind-Carbon-Copy
Go to the Top of This SecurityTracker Archive Page