[CORE SDI ADVISORY] SSH1 session key recovery vulnerability (8 forwarded messages...)

Dave Dittrich dittrich at cac.washington.edu
Mon Feb 12 16:27:33 PST 2001


---------- Forwarded message ----------
Date: Wed, 7 Feb 2001 15:48:58 -0300
Subject: [CORE SDI ADVISORY] SSH1 session key recovery vulnerability
From: Iván Arce <core.lists.bugtraq at CORE-SDI.COM>
To: BUGTRAQ at SECURITYFOCUS.COM

CORE SDI
http://www.core-sdi.com
SSH protocol 1.5 session key recovery vulnerability


Date Published: 2001-02-07

Advisory ID: CORE-20010116

Bugtraq ID: 2344

CVE CAN: Not currently assigned.

Title: Session Key recovery in SSH protocol 1.5

Class: Design/implementation error

Remotely Exploitable: Yes

Locally Exploitable: Yes

Release Mode: USER RELEASE

Vulnerability Description:

SSH is a widely used client-server application for authentication
and encryption of network communications. In order to ensure that all
data exchanged between client and server is kept confidential a
symmetric algorithm is used with a key obtained from the key exchange
and authentication process done upon connection from the client to
an SSH server.
A would be attacker could obtain and store all the encrypted packets
belonging to a specific client-server connection but that would
provide no real value unless she is able to:

. Decrypt them without having the session key used for the encryption
This is equivalent to breaking the crypto algorithm used.

or

. Exploit some design or implementation problem on either client or
server to obtain the session key and the proceed to decrypt the
stored session using any implementation of the crypto algorithm
used.

This advisory describes a vulnerability in the SSH 1.5 protocol
that allows an attacker to do the later.

The key exchange in SSH protocol 1.5 uses PKCS#1_1.5 public key
encryption standard to make the key exchange between client and
server upon connection.

An attack (see [1] and [2]) discovered by David Bleichenbacher
on PKCS#1_1.5 can be exploited to recover arbitrary session keys.

Combining Bleichenbacher's attack with a timing attack designed
to obtain information about crypto operations performed on a
SSH server it is possible to obtain a session key for an SSH
session and therefore decrypt it or even alter it if it is
still active.

Vulnerable Packages/Systems:

All versions of SSH supporting the protocol 1.5 key exchange.
This vulnerability applies to SSH servers only.

See the following section for vendor specific information.


Solution/Vendor Information/Workaround:

OpenSSH
The vulnerability is present in OpenSSH up to version 2.3.0,
although it is not possible to exploit it due to limits imposed
on the number of simultaneous connections the server is allowed
to handle,
Nonetheless, Markus Friedl of OpenSSH.com has produced a patch that
sets a random session key if RSA operations on the session key sent by
the client fail. This effectively solves the problem by closing the
oracle that leaks information.
The patch was integrated to the OpenSSH source tree on January 29, 2001

AppGate
The default configuration of the AppGate server is not
vulnerable since it has SSH-1 support disabled. However it
is possible for administrators to enable SSH-1 backwards
compatibility to be able to use legacy clients. Those customers
should apply the patches we have prepared. Patches can be
downloaded from the AppGate support web or requested from
support at appgate.com

Mindbright
The Mindbright ssh1-server is only an experimental product and
we are not aware of anybody actually using it, it has never been
sold or available as a separate entity. Since it is written in
java it will need a really extreme machine to be able to handle
the load needed to exploit this vulnerability. Anybody who feels
that they need a patch for it is welcome to contact
mindbright at mindbright.se.

SSH.com
ssh-1 up to version 1.2.31 is vulnerable.
The official response from SSH.com follows:

-SSH1 is deprecated and SSH.com does not support it
anymore, the official response is upgrade to SSH2
-The SSH1 compatibility code built into SSH-2.4.0 always executes a
fresh copy of SSHD1, which causes the server key to be regenerated
for every connection. Thus, the attack is not at all feasible when
using SSH1 with an SSH2 server in compatibility mode.
Ssh-2.4.0 also includes code for limiting the maximum number of
simultaneous connections. The maximum is controlled by the
MaxConnections flag in /etc/ssh2/sshd2_config or with the
--with-ssh-connection-limit=<limit> compile-time configure option.
However, as noted, the limit is not required for protection when using
SSH1 with SSHD2 in compatibility mode.
-The following unsupported and untested patch can be applied to
ssh-1.2.31 and earlier. It addresses the problem by regenerating the
server key when the RSA operations fail. This is done at a rate of
at most one key regeneration per minute to avoid possible DoS attacks.

-------------- cut here ----------------------------------------------

--- rsaglue.c 1999/12/10 23:27:25 1.8
+++ rsaglue.c 2001/02/03 09:42:05
@@ -264,7 +268,15 @@
mpz_clear(&aux);

if (value[0] != 0 || value[1] != 2)
- fatal("Bad result from rsa_private_decrypt");
+ {
+ static time_t last_kill_time = 0;
+ if (time(NULL) - last_kill_time > 60 && getppid() != 1)
+ {
+ last_kill_time = time(NULL);
+ kill(SIGALRM, getppid());
+ }
+ fatal("Bad result from rsa_private_decrypt");
+ }

for (i = 2; i < len && value[i]; i++)
;

-------------- cut here ---------------------------------------------

LSH
Not vulnerable. Does not support protocol version 1

Cisco Systems, F-Secure, other SSH server vendors
No information provided.

Additionally, advisories and information on security issues
in SSH can be obtained from:

http://www.core-sdi.com/advisories/buffer_over_ing.htm
http://www.core-sdi.com/advisories/ssh-advisory.htm
http://www.core-sdi.com/bid/1949
http://www.core-sdi.com/bid/1426
http://www.core-sdi.com/bid/1323
http://www.core-sdi.com/bid/1006
http://www.core-sdi.com/bid/843
http://www.core-sdi.com/bid/660

Vendor notified on: 2001-01-16

Credits:

This vulnerability was found and researched by Ariel Waissbein
and Agustin Azubel of CORE SDI, Buenos Aires, Argentina.

This advisory was drafted with the help of the SecurityFocus.com
Vulnerability Help Team. For more information or assistance drafting
advisories please mail vulnhelp at securityfocus.com.

This and other CORE SDI security advisories can be obtained from:

http://www.core-sdi.com/english/publications.html


Technical Description - Exploit/Concept Code:

In Section 1 we introduce the SSH1 key exchange, in Section 2 we
introduce the attack, finally in Section 3 we discuss the attack's
feasibility and argue why it is insecure to continue using
this protocol.

1) SSH1 KEY-EXCHANGE PROTOCOL DESCRIPTION:

1.1.- The keys.

Each host has a host unique permanent RSA key set which
identifies it. A host is a SSH server (referenced as server),
which runs the 'sshd' daemon or a SSH client (referenced as client)
which runs the 'ssh' client program.
The length of the host key is by default 1024 bits.

Each server has its own server RSA key set which is automatically
generated after a specified timeout (1 hour by default). This
key set is never saved in any file. The length of this key is by
default 768 bits. In every client-to-server connection, a 256 bits
session key is generated by the client using pseudo-random data
provided by the same client.
This session key will be used in a symmetric algorithm (e.g. DES,
Blowfish, 3DES) to encrypt the data flow on the connected channel
after the key exchange is completed.

To send the session key over an insecure channel to the server,
it is encrypted by the client with the server key and the server host
key together with other data using an asymmetric encryption algorithm
(RSA-PKCS #1 1.5) as we explain in Subsection 1.4. The purpose
of the two separate server keys is to make it impossible to decrypt
a captured session by breaking into the server machine and getting access
to the server key at a later time; one hour after the connection start
not even the server machine can decipher the session key!

1.2.- Initiating a connection.

Whenever a client connects to the server, the daemon forks. The parent
stays in a loop waiting to accept more connections and the child manages
the accepted connection. Before authenticating both endpoints, they do
an identification exchange.

1.3.- The identification exchange.

First, the server sends a formatted string to the client in plaintext,
specifying the protocol supported versions and the server version.
This string looks like "SSH-1.99-OpenSSH_2.3.0", where "1" denotes the
protocol version major number, "99" the protocol version minor number
and "OpenSSH_2.3.0" is the software version of the server.

If the client does not support the received protocol, it closes the
connection. If the protocol is supported by the client, it responds with
a formatted string of the same plaintext format. The server then checks
the client's response. If the versions do not match or the client
version
is not valid, the server closes the connection.
If the versions do match, the key exchange is started.

1.4.- The key exchange.

The server will send both of its public keys. First the server will fetch
64 bits from a PRNG, that will be used as a cookie to prevent IP
spoofing attacks and TCP sequence number prediction. This only affects
rhosts authentication.

The client must send back this cookie when the session key is sent.
This only works against somebody doing IP spoofing from a remote network;
any machine on the local network can still see outgoing packets and catch
the random cookie.

The server then builds a packet of type SSH_SMSG_PUBLIC_KEY, concatenating
the cookie, the size of the 'n' component of the RSA server key, the 'e'
public exponent of the RSA server key and the modulus 'n' of the RSA serve
r
key (the public RSA server key), the size of the 'n' component of the RSA
host key, the 'e' public exponent of the RSA host key and the modulus 'n'
of the RSA host key (the public RSA host key), the SSH protocol flags,
the supported symmetric ciphers, and the supported authentication methods.

Once the client has received the SSH_SMSG_PUBLIC_KEY packet,
it computes a session ID in the same way the server
does:

[mpaux.c:compute_session_id()]

The session ID is equal to a MD5 hash of the concatenation of
the modulus of the host key of the server, the modulus of the server
key and the server generated cookie.

session_id := MD5(HostKey_RSAModulus||ServerKey_RSAModulus||Cookie)

The length of a session_id is the same as the output of the MD5
function: 128 bits.

The client generates a session key of 256 bits fetching data from
a PRNG. This key will be the used in a symmetric algorithm to encrypt
all the future flow of this SSH session.

Before this key is encrypted and sent, the first 128 bits of this key,
are XORed with the session_id. The client then uses the RSA algorithm
(PKCS1 1.5) to encrypt consecutively the XORed session key and
session_id with the server key and host key.
Encryption is made using the smaller key first.

Finally the client builds a packet containing the symmetric
algorithm to use, the received cookie, the encrypted session key and
the SSH protocol flags and sends it to the server.

The server receives this packet and retrieves the symmetric algorithm
chosen by the client and checks its compliance sending a
"Warning: client selects unsupported cipher." message if it is not.

It then checks that the received cookie matches the old cookie sent,
sending another error message if it is not.

It retrieves the encrypted key, processes the SSH algorithm flags and
decrypts the session key (OpenSSH does an integrity check on the
packet lenght before this).

We explain this in detail since it is of great interest for our attack.
To do this we introduce the PKCS #1 1.5 encoding.

1.5 - PKCS#1 - 1.5 (from rsaglue.c in ssh-1.2.30)

To send a message m using a RSA public exponent e, with a public
modulus n, the encrypter encodes the message m as

M := 0x00 || 0x02 || P || 0x00 || m


where 0x00 and 0x02 are the value of the first 2 bytes in hexa,
and P is an hexadecimal padding string containing no zero octets.
The ciphertext is:
c := M^e mod (n) . (i.e. M to the e-th power modulo n)

To recover m, the decrypter calculates c^d, where d is the private
exponent, checks whether the first two bytes are 0x00 and 0x02
and calls the function fatal() in log-server.c closing the
connection if the check failed.
Otherwise it sets all the data after the second zero as the
message (in case the format is correct this will return m).

OpenSSH uses OpenSSL which behaves different, see the
RSA_padding_check_PCKS1_type2() function for more details.

The cleartext for this session key is recovered by checking which
is the bigger public modulus and decrypting first with the key
corresponding to the bigger modulus and secondly with the smaller
one (in case of a tie the server key goes first). This is done
using the rsa_private_decrypt() function.

When this is done the server computes the session key, and does
a XOR of the decrypted data with the computed session id to obtain
the session key generated by the client.

Finally the server sets the symmetric encryption scheme and key to
the ones chosen by the client, and sends a packet describing the success
to the client.

This packet is the first encrypted packet of the flow secured by the
symmetric algorithm.


2) ATTACK DESCRIPTION.

2.1.- Bleichenbacher's attack.

Daniel Bleichenbacher presented an adaptive ciphertext attack to
RSA encryption standard PKCS1_1.5 at the Crypto 98 Conference ([1]),
which on input of a ciphertext c, outputs the cleartext m corresponding
to this ciphertext.
To carry out this attack the attacker needs to make use of a decryption
oracle. As we shall see, this is automatically provided by the RSA
functions used in SSH1 ( or in the OpenSSL library used in
OpenSSH).

This is the protocol flaw that enables the attack we present.
Specifically, an attacker needs only to access an oracle that will
answer if a string c' calculated by her is or is not PKCS#1_1.5-format
compliant, even less, she only needs to know if it holds true that the
hexadecimal representation of the string (c')^d mod (n) starts with the
octets 0x00 and 0x02 (here d is the private secret exponent and n the
public modulus).

To decrypt a ciphertext without the private key, the attacker needs to
access to this oracle 2^{20} times (average-time complexity).
This estimation holds true for a 1024 bit key size.

We shall not explain the attack in detail. To decrypt a ciphertext c
an attacker will need to access the oracle with messages of the type
c.s^e mod (n)

where e and n are the public exponent and public modulus, and s is
chosen by the attacker algorithm following certain rules.

We refer to the paper [1] for further details.
In each step of the attack, the attacker finds a collection of intervals
in which the cleartext is contained, first starting with a big interval
of size 2^{1018}=2^{1024-16} and reducing it until a single interval of
size one - whose only member is the cleartext- is left.

2.2.- The attack on SSH-1

Suppose that we are sniffing a connection between a client and
the server. We can then easily detect when this connection starts and
get the packet containing the encrypted session key. We can then work in
parallel, saving all successive packets exchanged between server and
client, and at the same time attempt a session key decryption with the
attack we present.

Once the session key is decrypted all the saved encrypted packets sent
between this client and the server can be decrypted in a straight-forward
manner.

To obtain the session key we will make use of Bleichenbacher's attack
together with a simple timing attack technique.

Let c := E_{K1}(E_{K2}(K)) denote the captured ciphertext, where K1
and K2 are the server and host key (the order of these keys does not
alter the way in which the attack is made, since the order can be easily
deduced as we explain in the following section, we suppose without loss of
generality that K1 is the host key and K2 is the server key), K is the
session key or rather the plaintext string containing the session key, and
E_{A}(B) denotes RSA-PKCS1_1.5 encryption of the cleartext B using the
public
key A. The attack is divided in two main steps,

Firstly the attacker will first attempt to recover E_{K2}(K) from c using
a plain Bleichenbacher attack, and secondly K is calculated by the
attacker
from E_{K2}(K) using a reduction we explain in the next subsection
together
with Bleichenbacher's attack.

Notice that the calls to the function fatal() can be used as the
needed oracle.
Successful negotiation of a session key will end with
the reception of a SSH_SMSG_SUCCESS packet at the client. A failure
will end with the connection being shutdown due to the calls to the
fatal() function from within the rash_private_decrypt() function.

An attacker can -prior to the attack- determine what is the
time needed for the server to reach the connection shutdown call in the
fatal() function if the first encryption is not format compliant, and what
is the time needed for the server to reach it if the first encryption is
format compliant and the second encryption is not. This is basically
the way of retrieving answers from the oracle and it implies a timing
attack as well as a few modifications to Bleichenbacher's attack.

To carry out the attack and recover the session key the host key needs to
remain the same during the attack, we suppose that this is the case and
shall discuss the feasibility of this in the following section.

Suppose now that E_{K2}(K) is already calculated and known to the
attacker, and call c':=E_{K2}(K). The attacker then uses c' to recover K.
To do this, instead of accessing the oracle with messages of the form
c.s^e mod (n), she will access the oracle with messages of the form
c'.s'^{e'} mod (n'), where c' is defined as c':=E_{K2}(K), and e' and n'
are the second public exponent and modulus (corresponding to E_{K1}(-)),
and s' is chosen following the same rules as defined by Bleichenbacher's
attack.


3. Implementation and Feasibility

The estimation for the number of times needed to access the oracle on a
adaptive ciphertext Bleichenbacher's attack for a 1024 bits modulus is
approximately 2^{20}, as we said before. This means that the server
should handle about 2^{20} connections to make the first decryption,
i.e. to get E_{K2}(K). After this is done, to recover K, another
adaptive ciphertext attack of the same sort should be carried out, with
presumably less accesses to the oracle --say 2^{19}-- since the second
key is smaller than the first one, to recover K. Hence, to carry out the
attack we present here, an attacker should perform around
(2^{20}+2^{19}) connections to the server during the lifespan of
a server key K (default is one hour) which implies a rate of oracle
queries of around 400/sec.

Limiting the number of simultaneous connections to the server will
greatly reduce the feasibility of this attack, this is in fact a
standard feature in at least the OpenSSH implementation of SSH-1.

It is necessary to note that the attacker also needs to perform crypto
operations (RSA encryptions with a small exponent) for each query during
the attack but those are computationally cheaper the ones performed on the
server side.

This seems to make our attack infeasible for most cases. nonetheless,
high end servers are still a possible target for this attack. It is
also worth mentioning that the number of connections given is for the
average case and specifics cases will fall below the average.

We follow to discuss other vulnerable cases in which our attack becomes
feasible.

An issue to be taken into account is the order of the keys K1 and K2,
that is whether K1 is the server key and K2 the host key, or the other
way around.
This issue, we deferred to this section, is of some importance to our
attack.
As we mentioned the order of the keys is changed to K2 for the host key,
and K1 for the server key in case the size of K2 is strictly greater
than K1.

In that case, the attacker has limited time to recover E_{K2}(K)
(because K1 has a default timeout of one hour), but has an indefinite
amount of time to recover K from E_{K2}(K). This would make the attack
easier since it reduces the initial recovery attack to 2^{20} oracle
queries within an hour
The second phase could be done at a much slower connection rate.

It might also happen that the public modulus n is much smaller than the
specified values, and this lucky stroke would speed up the attack
considerably.

Another issue to be taken into account, is when the default settings
for the server key timeout are changed increasing the key lifespan
and thus the time window for the attack.
It is not likely, however, that the default settings for the key size will
be purposely reduced.

There is also a technology or rather server efficiency issue to be taken
into account. Although the average case of the attack we present seems
infeasible today, this might not be the case for specific attacks that
deviates from the average or for specific attack scenarios en the present
or the near future.

The conclusion of this report is that although the attack described
might not be a direct threat to the wide audience that relies on SSH1 for
secure network communications, there is, nonetheless an exploitable flaw
in the SSH-1 key exchange protocol that should be either fixed or
addressed during the deployment of SSH as a security component.

References

[1] Daniel Bleichenbacher, "Chosen ciphertext attacks on RSA
encryption standard PKCS #1", Advances in Cryptology,
CRYPTO 98. Springer.

[2] Daniel Bleichenbacher, Burt Kaliski and Jessica Staddon,
"Recent results on PKCS#1: RSA encryption standard ".
RSA Laboratories' Bulletin 7. http://www.rsa.com/rsalabs

$Id: SSH1-sessionkey-recovery.txt,v 1.9 2001/02/07 18:41:13 iarce Exp $

---

"Understanding. A cerebral secretion that enables one having it to know
a house from a horse by the roof on the house,
Its nature and laws have been exhaustively expounded by Locke,
who rode a house, and Kant, who lived in a horse." - Ambrose Bierce


==================[ CORE Seguridad de la Informacion S.A. ]=========
Iván Arce
Presidente
PGP Fingerprint: C7A8 ED85 8D7B 9ADC 6836 B25D 207B E78E 2AD1 F65A
email : iarce at core-sdi.com
http://www.core-sdi.com
Florida 141 2do cuerpo Piso 7
C1005AAG Buenos Aires, Argentina.
Tel/Fax : +(54-11) 4331-5402
=====================================================================





--- For a personal reply use iarce at core-sdi.com




---------- Forwarded message ----------
Date: Wed, 7 Feb 2001 14:26:46 -0800
Subject: Re: [CORE SDI ADVISORY] SSH1 session key recovery vulnerability
From: Dan Harkless <dan-bugtraq at DILVISH.SPEED.NET>
To: BUGTRAQ at SECURITYFOCUS.COM

=?iso-8859-1?Q?Iv=E1n_Arce?= <core.lists.bugtraq at CORE-SDI.COM> writes:

> Solution/Vendor Information/Workaround:

[...]

> SSH.com

> ssh-1 up to version 1.2.31 is vulnerable.

> The official response from SSH.com follows:

>

> -SSH1 is deprecated and SSH.com does not support it

> anymore, the official response is upgrade to SSH2

> -The SSH1 compatibility code built into SSH-2.4.0 always executes a

> fresh copy of SSHD1, which causes the server key to be regenerated

> for every connection. Thus, the attack is not at all feasible when

> using SSH1 with an SSH2 server in compatibility mode.


I run a version 1 ssh.com sshd out of inetd using Wietse Venema's tcpd
because tcp_wrappers support is incomplete/buggy in the daemon itself (at
least in 1.2.27 -- haven't re-tested the later versions to see if they fix
this). The daemon linked with libwrap doesn't support the rfc931 action and
I've had problems with it being overly permissive when specifying allowed IP
ranges.

In this case:

ssh stream tcp nowait root /usr/local/sbin/tcpd /usr/local/sbin/sshd -i

as in the 2.4.0 SSH1 compatibility case mentioned above, there's a fresh
daemon for each connection. Annoying waiting for the server key to be
generated for each connection if your machine isn't blazing fast, but a side
effect is that this attack is prevented.

----------------------------------------------------------------------
Dan Harkless | To prevent SPAM contamination, please
dan-bugtraq at dilvish.speed.net | do not mention this private email
SpeedGate Communications, Inc. | address in Usenet posts. Thank you.




---------- Forwarded message ----------
Date: Wed, 7 Feb 2001 19:33:52 -0300
Subject: Re: [CORE SDI ADVISORY] SSH1 session key recovery vulnerability
(errata)
From: Iván Arce <core.lists.bugtraq at CORE-SDI.COM>
To: BUGTRAQ at SECURITYFOCUS.COM

Just a small correction to the advisory just released:


> http://www.core-sdi.com/bid/1949

> http://www.core-sdi.com/bid/1426

> http://www.core-sdi.com/bid/1323

> http://www.core-sdi.com/bid/1006

> http://www.core-sdi.com/bid/843

> http://www.core-sdi.com/bid/660

>


should be:

http://www.securityfocus.com/bid/1949
http://www.securityfocus.com/bid/1426
http://www.securityfocus.com/bid/1323
http://www.securityfocus.com/bid/1006
http://www.securityfocus.com/bid/843
http://www.securityfocus.com/bid/660

sorry for the cut&paste glitch.
-ivan

---

"Understanding. A cerebral secretion that enables one having it to know
a house from a horse by the roof on the house,
Its nature and laws have been exhaustively expounded by Locke,
who rode a house, and Kant, who lived in a horse." - Ambrose Bierce


==================[ CORE Seguridad de la Informacion S.A. ]=========
Iván Arce
Presidente
PGP Fingerprint: C7A8 ED85 8D7B 9ADC 6836 B25D 207B E78E 2AD1 F65A
email : iarce at core-sdi.com
http://www.core-sdi.com
Florida 141 2do cuerpo Piso 7
C1005AAG Buenos Aires, Argentina.
Tel/Fax : +(54-11) 4331-5402
=====================================================================





--- For a personal reply use iarce at core-sdi.com




---------- Forwarded message ----------
Date: Thu, 8 Feb 2001 15:52:59 -0500
Subject: Re: [CORE SDI ADVISORY] SSH1 session key recovery vulnerability
From: Niels Provos <provos at CITI.UMICH.EDU>
To: BUGTRAQ at SECURITYFOCUS.COM

In message <073f01c09136$ddc04240$2e58a8c0 at ffornicario>, =?iso-8859-1?Q?Iv=E1n_
Arce?= writes:

> OpenSSH

> The vulnerability is present in OpenSSH up to version 2.3.0,

> although it is not possible to exploit it due to limits imposed

> on the number of simultaneous connections the server is allowed

> to handle,

This is a confusing way to put it. This attack is not feasible on
OpenSSH. The connection limits takes care of it. If you are running
OpenSSH 2.3.0, you are completely fine.

Niels.




---------- Forwarded message ----------
Date: Fri, 9 Feb 2001 14:38:02 -0500
Subject: severe error in SSH session key recovery patch
From: Matt Power <mhpower at bos.bindview.com>
To: bugtraq at securityfocus.com
Cc: ssh at clinet.fi, openssh-unix-dev at mindrot.org

http://www.core-sdi.com/advisories/ssh1_sessionkey_recovery.htm
includes the line of code:

kill(SIGALRM, getppid());

This is contained within what is listed as an "unsupported and
untested patch" developed by SSH.com.

The problem is that the arguments to "kill" are in the wrong order. In
other words, to obtain the effect that was apparently intended, the
line of code should have been

kill(getppid(), SIGALRM);

One effect is that the patch does not, in any way, help reduce the
risks associated with the session key recovery vulnerability, since
the parent process will not receive an ALRM signal and thus will not
regenerate a server key. The other possible effect is that there might
be a process whose pid is equal to the numerical value of SIGALRM, and
the value of getppid() might be a signal number that, if sent, would
have an adverse effect on that process and consequently an adverse
effect on system stability. (The call to "kill" is fine in the rare
case where SIGALRM and getppid() happen to be numerically equal.)

(This posting is intended to point out the error in the "kill" line of
that patch; it is not intended to provide a recommendation that the
patch be used if the "kill" line is corrected.)

To determine whether the corrected patch seems appropriate for one's
intended application, here are a few other factors to consider:

-- if sshd is run from tcpserver (see
http://cr.yp.to/ucspi-tcp/tcpserver.html) using a command line
such as "tcpserver 0 ssh /usr/local/sbin/sshd -i", the
"kill(getppid(), SIGALRM);" will cause the tcpserver process to
terminate. Unless another process exists that will automatically
restart that tcpserver process, access to the system via ssh will
be no longer available. There may be a version of inetd or an
inetd derivative that will also terminate upon receiving an ALRM
signal. However, it is commonly the case that an inetd process
will not terminate if it receives an ALRM signal.

It happens to be the case that the patch involving
"kill(getppid(), SIGALRM);" is not needed if sshd is run from
either tcpserver or inetd. Still, some organizations may be
deploying a version of sshd with this patch onto systems where
tcpserver is used, especially if they are using an sshd package
that was put together without this tcpserver issue in mind.

It is not a bug in tcpserver that the process terminates when
it receives an ALRM signal. Any "normal" program started by
tcpserver will not be sending an ALRM signal to getppid(), so
one shouldn't expect the design of tcpserver to anticipate that.

Running an sshd supporting SSH protocol 1.5 from inetd/tcpserver
rather than standalone is a tradeoff between DoS concerns and
session-key-recovery concerns. The right decision will not be
the same in all environments.

-- With the patch, the lifespan of the server key still does not go
below one minute. As mentioned in CORE SDI's advisory, the number
of server connections necessary to carry out the attack is
normally very large but "the number of connections given is for
the average case and specifics cases will fall below the
average". This suggests that is not entirely out of the question
for the attack to succeed within one minute. If that risk is not
appropriate in one's environment, then other measures (which may
include inetd/tcpserver but may also include desupporting use of
SSH protocol 1.5) are needed.

Matt Power
BindView Corporation, RAZOR Team
mhpower at bos.bindview.com




---------- Forwarded message ----------
Date: Fri, 9 Feb 2001 16:32:44 -0300
Subject: Re: [CORE SDI ADVISORY] SSH1 session key recovery vulnerability
From: Iván Arce <core.lists.bugtraq at CORE-SDI.COM>
To: BUGTRAQ at SECURITYFOCUS.COM

Hello,

Yet another error in the advisory released last Wednesday.

----- Original Message -----
From: "Iván Arce" <core.lists.bugtraq at core-sdi.com>
Newsgroups: core.lists.bugtraq
To: <BUGTRAQ at SECURITYFOCUS.COM>
Sent: Wednesday, February 07, 2001 6:25 PM
Subject: [CORE SDI ADVISORY] SSH1 session key recovery vulnerability



> CORE SDI

> http://www.core-sdi.com

> SSH protocol 1.5 session key recovery vulnerability

>

>


...

> -------------- cut here ----------------------------------------------

>

> --- rsaglue.c 1999/12/10 23:27:25 1.8

> +++ rsaglue.c 2001/02/03 09:42:05

> @@ -264,7 +268,15 @@

> mpz_clear(&aux);

>

> if (value[0] != 0 || value[1] != 2)

> - fatal("Bad result from rsa_private_decrypt");

> + {

> + static time_t last_kill_time = 0;

> + if (time(NULL) - last_kill_time > 60 && getppid() != 1)

> + {

> + last_kill_time = time(NULL);

> + kill(SIGALRM, getppid());


... This is wrong wrong wrong and will produce unpredictable results
on the server machine and does not fix the vulnerability either.
The correct line is:

+ kill(getppid(),SIGALRM);

Thanks to Matt Power from the Bindview RAZOR Team for
pointing this out.

The advisory at our web page has been updateed to reflect this
change.


-ivan


---

"Understanding. A cerebral secretion that enables one having it to know
a house from a horse by the roof on the house,
Its nature and laws have been exhaustively expounded by Locke,
who rode a house, and Kant, who lived in a horse." - Ambrose Bierce


==================[ CORE Seguridad de la Informacion S.A. ]=========
Iván Arce
Presidente
PGP Fingerprint: C7A8 ED85 8D7B 9ADC 6836 B25D 207B E78E 2AD1 F65A
email : iarce at core-sdi.com
http://www.core-sdi.com
Florida 141 2do cuerpo Piso 7
C1005AAC Buenos Aires, Argentina.
Tel/Fax : +(54-11) 4331-5402
=====================================================================


--- For a personal reply use iarce at core-sdi.com




---------- Forwarded message ----------
Date: Sat, 10 Feb 2001 08:31:55 GMT
Subject: Re: [CORE SDI ADVISORY] SSH1 session key recovery vulnerability
From: David Wagner <daw at MOZART.CS.BERKELEY.EDU>
To: BUGTRAQ at SECURITYFOCUS.COM

Maybe there's a lesson to be learned from this SSH advisory: "Attacks
always get better; they never get worse" [1].

I spent a little time looking for Bleichenbacher attacks on SSH more than
two years ago. There was obviously a side channel disclosing decryption
failures, but the best attack I could find was an an obscure 'academic
attack' that had fairly hefty resource requirements: 2^20 interactions
with the server, and ability to do TCP hijacking.

At the time, I interpreted this as only a very minor attack, due to the
strong assumptions required. Back in June 1998, I fired off a warning
note to all the SSH folks I could think of [2], but quickly gave up and
forgot about the whole thing when I never heard back from anyone [3].

I was mistaken in my assessment. We now know that Bleichenbacher
attacks are a real threat. CORE SDI has described an insightful advance
in analysis, a clever trick that can be used to exploit the same side
channel that I wrongly considered useful only for academic attacks [4].
In short, I'm impressed by CORE SDI's contributions and humbled at
overlooking the possibility for practical attacks.

The lesson here seems clear. I should have known better: the mere
presence of the side channel should have been enough justification
to justify fixing the code, despite the impractical nature of attacks
known then. Attacks only get better, and once the attacker gets a foot
in the door with this sort of weakness, who knows where it will all end?
Next time, maybe I'll know better; in the meantime, I thought the lesson
might be worth mentioning.



[1] I'm indebted to Bruce Schneier for this observation; see his April
15th Crypto-gram newsletter.

[2] http://www.cs.berkeley.edu/~daw/tmp/ssh
Available upon request (my website seems to be down at the moment,
but hopefully will be back).

[3] As a side note, this indicates to me that the vulnerability reporting
process in place at SSH could probably be improved. I sent several
repeated emails, but never heard once heard back from anyone, and soon
gave up.

[4] As one who has been previously guilty of perpetrating an 'academic
attack' or two (when your analysis starts with "first guess 192 bits of
the key", you know you're in the land of 'academic attacks'!), it seems
that I can err equally well in both directions...




---------- Forwarded message ----------
Date: Sun, 11 Feb 2001 12:07:39 -0500
Subject: Re: severe error in SSH session key recovery patch
From: Andrew Brown <atatat at ATATDOT.NET>
To: BUGTRAQ at SECURITYFOCUS.COM


> -- With the patch, the lifespan of the server key still does not go

> below one minute. As mentioned in CORE SDI's advisory, the number

> of server connections necessary to carry out the attack is

> normally very large but "the number of connections given is for

> the average case and specifics cases will fall below the

> average". This suggests that is not entirely out of the question

> for the attack to succeed within one minute. If that risk is not

> appropriate in one's environment, then other measures (which may

> include inetd/tcpserver but may also include desupporting use of

> SSH protocol 1.5) are needed.


1) {
2) static time_t last_kill_time = 0;
3) if (time(NULL) - last_kill_time > 60 && getppid() != 1)
4) {
5) last_kill_time = time(NULL);
6) kill(SIGALRM, getppid());
7) }
8) fatal("Bad result from rsa_private_decrypt");
9) }

actually...if we look at the lines that the patch adds, i think it's
pretty clear that the variable last_kill_time, declared at line 2 to
be static and initialized to 0, will always be 0 at line 3 (since it
can't get set to anything else from other code...it's static), which
means that the kill (and setting the actual of last_kill_time to
something other than 0) will almost always take place (now - 0 is
usually a lot more than 60), and the fact that it finally get set
doesn't mean anything to anyone, since the only process that recorded
that the signal was sent immediately exits at line 8.

unless i'm missing something, this turns the vulnerability from a
possible (but difficult) theft of a session key to very easy denial of
service attack. all i need to do is keep connecting and screwing up
and your main sshd will churn on and on making itself new server keys.

--

|-----< "CODE WARRIOR" >-----|

codewarrior at daemon.org * "ah! i see you have the internet
twofsonet at graffiti.com (Andrew Brown) that goes *ping*!"
andrew at crossbar.com * "information is power -- share the wealth."





More information about the Linux mailing list