exploit the possibilities
Home Files News &[SERVICES_TAB]About Contact Add New

ssh1_deattack.txt

ssh1_deattack.txt
Posted Feb 9, 2001
Site core-sdi.com

ORE SDI Security Advisory CORE-20010207 - SSH1 CRC-32 compensation attack detector vulnerability. In 1998 a design flaw was fixed in SSH1 which allowed an attacker to inject malicious packets into an SSH session. In fixing this bug, a new vulnerability in deattack.c was created which allows remote attackers to execute arbitrary commands on the server. OpenSSH prior to v2.3.0 is vulnerable, as are ssh.com's ssh-1.2.24 through 1.2.31, and F-Secure SSH-1.3.x.

tags | remote, arbitrary
SHA-256 | fdc00415fdba450c4d5644f7ad33db0ce3a7dd4e86d112d5602ed9d33c296ded

ssh1_deattack.txt

Change Mirror Download
     CORE SDI S.A. Security Advisory

February 8th, 2001

SSH1 CRC-32 compensation attack detector vulnerability

Date Published: 2001-02-08

Advisory ID: CORE-20010207

Bugtraq ID: 2347

CVE CAN: CAN-2001-0144

Title: SSH1 CRC-32 compensation attack detector vulnerability

Class: Boundary Error Condition

Remotely Exploitable: Yes

Locally Exploitable: Yes

Release Mode: FORCED RELEASE

Vulnerability Description:

SSH is a widely used client-server application for authentication and encryption of network
communications.

In 1998 Ariel Futoransky and Emiliano Kargieman [2] 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.

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
F-Secure SSH-1.3.x is vulnerable.
Contact the vendor for a fix.

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 MindtTerm client does not have this vulnerability.

TTSSH
Not vulnerable.
All version 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 (http://www.mud.de/se/jta/)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/Vendor Information/Workaround:

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.
Additionally, advisories and information on security issues in SSH can be obtained from:
http://www.core-sdi.com/advisories/ssh1_sessionkey_recovery.htm
http://www.core-sdi.com/advisories/buffer_over_ing.htm
http://www.core-sdi.com/advisories/ssh-advisory.htm
http://www.securityfocus.com/bid/2347
http://www.securityfocus.com/bid/2222
http://www.securityfocus.com/bid/2117
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

--------------------- begin deattack 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 -------------------

Vendors notified on: 2001-02-07

This advisory has been released early due to the disclosure of information regarding the
problem in public forums.

Credits:

This vulnerability was found by Michal Zalewski of the Bindview RAZOR Team.

We thank Scott Blake and Steve Manzuik of the Bindview RAZOR Team for their cooperation
coordinating the report and release process of this advisory.

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

http://www.core-sdi.com/publications.htm

Technical Description - Exploit/Concept Code:

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 cipher text 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 behaviors and are thus vulnerable. Systems which
have the older behaviors 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.

References

[1] http://www.core-sdi.com/soft/ssh/ssh.pdf

Copyright notice

The contents of this advisory are copyright (c) 2001 CORE SDI Inc. and may be distributed
freely provided that no fee is charged for this distribution and the authors are given
credit.

All the product names mentioned herein are trademarks of their respective owners.
Login or Register to add favorites

File Archive:

March 2024

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Mar 1st
    16 Files
  • 2
    Mar 2nd
    0 Files
  • 3
    Mar 3rd
    0 Files
  • 4
    Mar 4th
    32 Files
  • 5
    Mar 5th
    28 Files
  • 6
    Mar 6th
    42 Files
  • 7
    Mar 7th
    17 Files
  • 8
    Mar 8th
    13 Files
  • 9
    Mar 9th
    0 Files
  • 10
    Mar 10th
    0 Files
  • 11
    Mar 11th
    15 Files
  • 12
    Mar 12th
    19 Files
  • 13
    Mar 13th
    21 Files
  • 14
    Mar 14th
    38 Files
  • 15
    Mar 15th
    15 Files
  • 16
    Mar 16th
    0 Files
  • 17
    Mar 17th
    0 Files
  • 18
    Mar 18th
    10 Files
  • 19
    Mar 19th
    32 Files
  • 20
    Mar 20th
    46 Files
  • 21
    Mar 21st
    16 Files
  • 22
    Mar 22nd
    13 Files
  • 23
    Mar 23rd
    0 Files
  • 24
    Mar 24th
    0 Files
  • 25
    Mar 25th
    12 Files
  • 26
    Mar 26th
    31 Files
  • 27
    Mar 27th
    19 Files
  • 28
    Mar 28th
    0 Files
  • 29
    Mar 29th
    0 Files
  • 30
    Mar 30th
    0 Files
  • 31
    Mar 31st
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2022 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close