|
Brought to you by:
Suppliers of:
|
|
|
| |
SSH is a widely used client-server application for authentication and encryption of network communications. In 1998 Ariel Futoransky and Emiliano Kargieman discovered a design flaw in the SSH1 protocol (protocol 1.5) that could lead an attacker to inject malicious packets into an SSH encrypted stream that would allow execution of arbitrary commands on either client or server.
The problem was not fixable without breaking the protocol 1.5 semantics and thus a patch was devised that would detect an attack that exploited the vulnerability found. The attack detection is done in the file deattack.c from the SSH1 source distribution.
A vulnerability was found in the attack detection code that could lead to the execution of arbitrary code in SSH servers and clients that incorporated the patch. |
| |
Credit:
The information has been provided by Michal Zalewski of the Bindview RAZOR Team.
|
| |
Vulnerable Packages/Systems:
This problem affects both SSH servers and clients.
All versions of SSH supporting the protocol 1 (1.5) that use the CRC compensation attack detector are vulnerable. See below for vendor specific information.
OpenSSH
OpenSSH versions prior to 2.3.0 are vulnerable.
OpenSSH versions 2.3.0 and above are not vulnerable, source changes in deattack.c that fix this problem were incorporated into the source tree on October 31st, 2000.
SSH.com
ssh-1.2.24 up to , and including, ssh-1.2.31 are vulnerable.
Versions prior to 1.2.24 did not include the CRC compensation attack detector. The official response from SSH.com follows:
- SSH-2.x is not vulnerable
- SSH1 is deprecated, and not supported, upgrade to SSH2
- Nonetheless the proposed patch has been applied to the ssh-1.2.x source tree, future releases of ssh-1.2.x will have the bug closed.
F-Secure SSH
Versions prior to F-Secure SSH-1.3.11-2 are vulnerable.
This vulnerability was fixed in F-Secure SSH1 1.3.11-2 released 9th Feb 2001.
AppGate
The default configuration of the AppGate server is not vulnerable since it has SSH-1 support disabled. However, customers who need ssh1-support can contact support@appgate.com to get patches.
Mindbright
The MindTerm client does not have this vulnerability.
TTSSH
Not vulnerable.
All versions that incorporated the attack detector are not vulnerable.
LSH
Not vulnerable. LSH does not support SSH protocol 1.
JavaSSH
Not vulnerable.
The Java Telnet/SSH Applet does not include CRC attack detection. A security note regarding Java SSH plugin can be found on: http://www.mud.de/se/jta/doc/plugins/SSH.html.
OSSH (by Bjoern Groenvall)
OSSH 1.5.7 and below is vulnerable. The problem has been fixed in version 1.5.8
Cisco SSH
Cisco SSH does not appear to be vulnerable.
Solution:
The patch included should be applied to the file deattack.c from the ssh-1.2.31 (and below) source distribution.
Contact your SSH vendor for a fix if source code is not available.
--------------------- begin dettack patch ------------------
This is the patch for ssh-1.2.31 package.
Using the patch:
Copy the ssh-1.2.31.tar.gz package and the ssh-1.2.31-deattack.patch in a directory.
Decompress the ssh-1.2.31.tar.gz package:
tar xzvf ssh-1.2.31.tar.gz
Apply the patch:
patch < ssh-1.2.31-deattach.patch
Compile the ssh package.
--- ssh-1.2.31/deattack.c-old Wed Feb 7 19:45:16 2001
+++ ssh-1.2.31/deattack.c Wed Feb 7 19:54:11 2001
@@ -79,7 +79,7 @@
detect_attack(unsigned char *buf, word32 len, unsigned char *IV)
{
static word16 *h = (word16 *) NULL;
- static word16 n = HASH_MINSIZE / HASH_ENTRYSIZE;
+ static word32 n = HASH_MINSIZE / HASH_ENTRYSIZE;
register word32 i, j;
word32 l;
register unsigned char *c;
--------------------- end deattack patch -------------------
Technical Description:
Most SSH distributions incorporated the file deattack.c released by CORE SDI in 1998. The file implements an algorithm to detect attempts to exploit the CRC-32 compensation attack by passing the ssh packets received from the network to the detect_attack() function in deattack.c
...
/*
detect_attack
Detects a crc32 compensation attack on a packet
*/
int
detect_attack(unsigned char *buf, word32 len, unsigned char *IV)
{
static word16 *h = (word16 *) NULL;
(*) static word16 n = HASH_MINSIZE / HASH_ENTRYSIZE;
register word32 i, j;
word32 l;
...
Buf is the ssh packet received, len is the length of that packet The received packet is comprised of several blocks of ciphertext of size SSH_BLOCKSIZE and each of them is checked against the others to verify that different packets don't have the same CRC value, such behavior is symptom of an attack. The detection is done using a hash table that is dynamically allocated based on the size of the received packet.
...
for (l = n; l < HASH_FACTOR(len / SSH_BLOCKSIZE); l = l << 2);
if (h == NULL)
{
debug("Installing crc compensation attack detector.");
n = l;
h = (word16 *) xmalloc(n * sizeof(word16));
} else
...
Due to the improper declaration of 'n' above (it should be a word32) by sending crafted large ssh packets (length > 2^16) it is possible to make the vulnerable code perform a call to xmalloc() with an argument of 0, which will return a pointer into the program's address space.
It is worth mentioning that existing standards promote two possible behaviors for malloc() when it is called with an argument of 0:
- Failure, returning NULL
- Success, returning a valid address pointing at a zero-sized object.
Most modern systems implement the later behavior and are thus vulnerable. Systems that have the older behavior will abort the connection due to checks within xmalloc()
It is then possible to abuse the following code to in order write to arbitrary memory locations in the program (ssh server or client) address space, thus allowing an attacker to execute arbitrary code on the vulnerable machine, see lines marked with (*):
for (c = buf, j = 0; c < (buf + len); c += SSH_BLOCKSIZE, j++)
{
(*) for (i = HASH(c) & (n - 1); h[i] != HASH_UNUSED;
i = (i + 1) & (n - 1))
{
if (h[i] == HASH_IV)
{
if (!CMP(c, IV))
{
if (check_crc(c, buf, len, IV))
return (DEATTACK_DETECTED);
else
break;
}
} else if (!CMP(c, buf + h[i] * SSH_BLOCKSIZE))
{
if (check_crc(c, buf, len, IV))
return (DEATTACK_DETECTED);
else
break;
}
}
(*) h[i] = j;
}
A would-be attacker does not need to authenticate to the SSH server first or to have the packets encrypted in a meaningful way to perform the attack. Even if that was the case, the session key used for encrypting is chosen by the ssh client and it is therefore trivial to implement an exploit (in the sense of the cryptography knowledge required to do it). However, a small degree of knowledge in exploit code development would be needed to implement a working exploit.
Exploit:
To reproduce this condition, run your sshd server on localhost under gdb with '-d' switch (to avoid forking). Then try (using OpenSSH client - ssh.com client software crops the login name):
$ ssh -v -l `perl -e '{print "A"x88000}'` localhost
|
|
|
|
|
