This is the 4th revision of the Advisory.
This document can be found at: http://www.openssh.com/txt/preauth.adv
1. Versions affected:
Serveral versions of OpenSSH's sshd between 2.3.1 and 3.3
contain an input validation error that can result in an
integer overflow and privilege escalation.
All versions between 2.3.1 and 3.3 contain a bug in the
PAMAuthenticationViaKbdInt code.
All versions between 2.9.9 and 3.3 contain a bug in the
ChallengeResponseAuthentication code.
OpenSSH 3.4 and later are not affected.
OpenSSH 3.2 and later prevent privilege escalation if
UsePrivilegeSeparation is enabled in sshd_config. OpenSSH
3.3 enables UsePrivilegeSeparation by default.
Although some earlier versions are not affected upgrading
to OpenSSH 3.4 is recommended, because OpenSSH 3.4 adds
checks for a class of potential bugs.
2. Impact:
This bug can be exploited remotely if
ChallengeResponseAuthentication
is enabled in sshd_config. This option is enabled
by default on OpenBSD and other systems.
Affected are at least systems supporting s/key over
SSH protocol version 2 (OpenBSD, FreeBSD and NetBSD
as well as other systems supporting s/key with SSH).
Exploitablitly of systems using
PAMAuthenticationViaKbdInt
has not been verified.
3. Short-Term Solution:
Disable ChallengeResponseAuthentication in sshd_config.
and
Disable PAMAuthenticationViaKbdInt in sshd_config.
Alternatively you can prevent privilege escalation
if you enable UsePrivilegeSeparation in sshd_config.
4. Solution:
Upgrade to OpenSSH 3.4 or apply the following patches.
5. Credits:
ISS.
6. Release Process:
Information release was handled in the following way:
a. We alerted the community via a number of news sites and large
public mailing lists that a major security issue was coming,
and that they should upgrade to OpenSSH >= 3.2, and enable
UsePrivilegeSeparation as soon as possible. We also released
OpenSSH 3.3 at the same time, without a fix for this serious
new issue. The goal was to place the community on a security
stance.
b. We could not alert the community that disabling
ChallengeResponseAuthentication solved the problem, since
this would highlight that the bug is in about 500 out of
27,000 lines of code.
c. We could not alert the community that the bug was SSH2-only,
and tell them to disable protocol 2, since would have focused
the problem in about 5,000 out of 27,000 lines of code. (And
we did not think of this possible solution until after ISS had
released their advisory).
d. We did not tell people which versions were vulnerable, since
the 2.9 to 2.9.9 transition was largely a rewrite of the
ChallengeResponseAuthentication subsystem. This would have
highlighted that as the problem area.
e. We believed very strongly that the issue was unknown in the
Blackhat community at the time. We also made the decision based
on the subtlety of the problem. Finally, we believe that the SSH
protocol is a security infrastructure protocol (with DNS and BGP),
and that issues of this scope require more gentle care.
f. We did not alert vendor contacts with detailed vulnerability
information, since the list of vendors who include OpenSSH
numbers around 80+. We were sure that any disclosure would leak
very quickly. Another vulnerability came to our attention at
roughly the same time (BSD resolver) and started leaking within
5 hours of vendor notification, so we tried to be very careful.
g. We did not have a complete list of vulnerable systems because
ISS did not do very complete testing, and we did not have
access to all the systems to test on. Even so, we would not
have wanted to alert the vendors as to which are vulnerable,
because they might have figured out their configuration options
and leaked the information.
h. Some vendors were initally upset by this policy of non-disclosure,
largely because the UsePrivilegeSeparation code was only about 90%
functional in OpenSSH 3.3:
- old linux kernels needed Compression disabled
- extended Linux PAM did not work (but that is where
the ChallengeResponseAuthentication bug was)
Over a 48 hour period, a few of these vendors rapidly helped us
to get these problems resolved, and we were able to release
OpenSSH 3.4 which solved these problems to 99% user satisfaction,
on almost all systems.
The most helpful vendors were OpenWall Linux and Debian.
i. ISS suddenly insisted on an early release of their advisory,
4 days earlier than ISS and we had planned. Some of us were awake
for 37 hours to get OpenSSH 3.4 out the door with the fix, at the
same time as the ISS advisory.
j. We contacted CERT, and they released their announcement of this
issue in record time -- around 24 hours. Dealing with CERT and
ISS took more than 5 hours of telephone time.
k. We have received mail from many users, including large and
significant organizations, who were able to take a security
stance by following our instructions about UsePrivilegeSeparation,
disabling OpenSSH, filtering port 22, guessing at functional
reduction, or preparing themselves for a new release at any time.
l. We have not heard of a single machine which was broken into as
a result of our release announcement method.
m. The first public attack program for the vulnerability was posted
to BUGTRAQ within a day after OpenSSH 3.4 was released, apparently
having been written based on the bug description.
We feel that this method of releasing served the community best for
a "contained" vulnerability of this kind. We do not suggest this is
neccessarily the correct information release process for all problems,
and as firm believers of full disclosure have never suggested that,
though we believe that disclosure must be carefully handled.
Appendix:
A:
Index: auth2-chall.c
===================================================================
RCS file: /cvs/src/usr.bin/ssh/auth2-chall.c,v
retrieving revision 1.18
diff -u -r1.18 auth2-chall.c
--- auth2-chall.c 19 Jun 2002 00:27:55 -0000 1.18
+++ auth2-chall.c 26 Jun 2002 09:37:03 -0000
@@ -256,6 +256,8 @@
authctxt->postponed = 0; /* reset */
nresp = packet_get_int();
+ if (nresp > 100)
+ fatal("input_userauth_info_response: nresp too big %u", nresp);
if (nresp > 0) {
response = xmalloc(nresp * sizeof(char*));
for (i = 0; i < nresp; i++)
B:
Index: auth2-pam.c
===================================================================
RCS file: /var/cvs/openssh/auth2-pam.c,v
retrieving revision 1.12
diff -u -r1.12 auth2-pam.c
--- auth2-pam.c 22 Jan 2002 12:43:13 -0000 1.12
+++ auth2-pam.c 26 Jun 2002 10:12:31 -0000
@@ -140,6 +140,15 @@
nresp = packet_get_int(); /* Number of responses. */
debug("got %d responses", nresp);
+
+ if (nresp != context_pam2.num_expected)
+ fatal("%s: Received incorrect number of responses "
+ "(received %u, expected %u)", __func__, nresp,
+ context_pam2.num_expected);
+
+ if (nresp > 100)
+ fatal("%s: too many replies", __func__);
+
for (i = 0; i < nresp; i++) {
int j = context_pam2.prompts[i];
This document can be found at: http://www.openssh.com/txt/preauth.adv
1. Versions affected:
Serveral versions of OpenSSH's sshd between 2.3.1 and 3.3
contain an input validation error that can result in an
integer overflow and privilege escalation.
All versions between 2.3.1 and 3.3 contain a bug in the
PAMAuthenticationViaKbdInt code.
All versions between 2.9.9 and 3.3 contain a bug in the
ChallengeResponseAuthentication code.
OpenSSH 3.4 and later are not affected.
OpenSSH 3.2 and later prevent privilege escalation if
UsePrivilegeSeparation is enabled in sshd_config. OpenSSH
3.3 enables UsePrivilegeSeparation by default.
Although some earlier versions are not affected upgrading
to OpenSSH 3.4 is recommended, because OpenSSH 3.4 adds
checks for a class of potential bugs.
2. Impact:
This bug can be exploited remotely if
ChallengeResponseAuthentication
is enabled in sshd_config. This option is enabled
by default on OpenBSD and other systems.
Affected are at least systems supporting s/key over
SSH protocol version 2 (OpenBSD, FreeBSD and NetBSD
as well as other systems supporting s/key with SSH).
Exploitablitly of systems using
PAMAuthenticationViaKbdInt
has not been verified.
3. Short-Term Solution:
Disable ChallengeResponseAuthentication in sshd_config.
and
Disable PAMAuthenticationViaKbdInt in sshd_config.
Alternatively you can prevent privilege escalation
if you enable UsePrivilegeSeparation in sshd_config.
4. Solution:
Upgrade to OpenSSH 3.4 or apply the following patches.
5. Credits:
ISS.
6. Release Process:
Information release was handled in the following way:
a. We alerted the community via a number of news sites and large
public mailing lists that a major security issue was coming,
and that they should upgrade to OpenSSH >= 3.2, and enable
UsePrivilegeSeparation as soon as possible. We also released
OpenSSH 3.3 at the same time, without a fix for this serious
new issue. The goal was to place the community on a security
stance.
b. We could not alert the community that disabling
ChallengeResponseAuthentication solved the problem, since
this would highlight that the bug is in about 500 out of
27,000 lines of code.
c. We could not alert the community that the bug was SSH2-only,
and tell them to disable protocol 2, since would have focused
the problem in about 5,000 out of 27,000 lines of code. (And
we did not think of this possible solution until after ISS had
released their advisory).
d. We did not tell people which versions were vulnerable, since
the 2.9 to 2.9.9 transition was largely a rewrite of the
ChallengeResponseAuthentication subsystem. This would have
highlighted that as the problem area.
e. We believed very strongly that the issue was unknown in the
Blackhat community at the time. We also made the decision based
on the subtlety of the problem. Finally, we believe that the SSH
protocol is a security infrastructure protocol (with DNS and BGP),
and that issues of this scope require more gentle care.
f. We did not alert vendor contacts with detailed vulnerability
information, since the list of vendors who include OpenSSH
numbers around 80+. We were sure that any disclosure would leak
very quickly. Another vulnerability came to our attention at
roughly the same time (BSD resolver) and started leaking within
5 hours of vendor notification, so we tried to be very careful.
g. We did not have a complete list of vulnerable systems because
ISS did not do very complete testing, and we did not have
access to all the systems to test on. Even so, we would not
have wanted to alert the vendors as to which are vulnerable,
because they might have figured out their configuration options
and leaked the information.
h. Some vendors were initally upset by this policy of non-disclosure,
largely because the UsePrivilegeSeparation code was only about 90%
functional in OpenSSH 3.3:
- old linux kernels needed Compression disabled
- extended Linux PAM did not work (but that is where
the ChallengeResponseAuthentication bug was)
Over a 48 hour period, a few of these vendors rapidly helped us
to get these problems resolved, and we were able to release
OpenSSH 3.4 which solved these problems to 99% user satisfaction,
on almost all systems.
The most helpful vendors were OpenWall Linux and Debian.
i. ISS suddenly insisted on an early release of their advisory,
4 days earlier than ISS and we had planned. Some of us were awake
for 37 hours to get OpenSSH 3.4 out the door with the fix, at the
same time as the ISS advisory.
j. We contacted CERT, and they released their announcement of this
issue in record time -- around 24 hours. Dealing with CERT and
ISS took more than 5 hours of telephone time.
k. We have received mail from many users, including large and
significant organizations, who were able to take a security
stance by following our instructions about UsePrivilegeSeparation,
disabling OpenSSH, filtering port 22, guessing at functional
reduction, or preparing themselves for a new release at any time.
l. We have not heard of a single machine which was broken into as
a result of our release announcement method.
m. The first public attack program for the vulnerability was posted
to BUGTRAQ within a day after OpenSSH 3.4 was released, apparently
having been written based on the bug description.
We feel that this method of releasing served the community best for
a "contained" vulnerability of this kind. We do not suggest this is
neccessarily the correct information release process for all problems,
and as firm believers of full disclosure have never suggested that,
though we believe that disclosure must be carefully handled.
Appendix:
A:
Index: auth2-chall.c
===================================================================
RCS file: /cvs/src/usr.bin/ssh/auth2-chall.c,v
retrieving revision 1.18
diff -u -r1.18 auth2-chall.c
--- auth2-chall.c 19 Jun 2002 00:27:55 -0000 1.18
+++ auth2-chall.c 26 Jun 2002 09:37:03 -0000
@@ -256,6 +256,8 @@
authctxt->postponed = 0; /* reset */
nresp = packet_get_int();
+ if (nresp > 100)
+ fatal("input_userauth_info_response: nresp too big %u", nresp);
if (nresp > 0) {
response = xmalloc(nresp * sizeof(char*));
for (i = 0; i < nresp; i++)
B:
Index: auth2-pam.c
===================================================================
RCS file: /var/cvs/openssh/auth2-pam.c,v
retrieving revision 1.12
diff -u -r1.12 auth2-pam.c
--- auth2-pam.c 22 Jan 2002 12:43:13 -0000 1.12
+++ auth2-pam.c 26 Jun 2002 10:12:31 -0000
@@ -140,6 +140,15 @@
nresp = packet_get_int(); /* Number of responses. */
debug("got %d responses", nresp);
+
+ if (nresp != context_pam2.num_expected)
+ fatal("%s: Received incorrect number of responses "
+ "(received %u, expected %u)", __func__, nresp,
+ context_pam2.num_expected);
+
+ if (nresp > 100)
+ fatal("%s: too many replies", __func__);
+
for (i = 0; i < nresp; i++) {
int j = context_pam2.prompts[i];