6069944 2001-02-08 20:54 -0300 /317 rader/ Iván_Arce <core.lists.bugtraq@CORE-SDI.COM>
Sänt av: joel@lysator.liu.se
Importerad: 2001-02-09 02:17 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: core.lists.bugtraq@CORE-SDI.COM
Mottagare: Bugtraq (import) <15314>
Markerad av 2 personer.
Ärende: [CORE SDI ADVISORY] SSH1 CRC-32 compensation attack detector
------------------------------------------------------------
vulnerability
From: Iván_Arce <core.lists.bugtraq@CORE-SDI.COM>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <060501c09221$57784610$2e58a8c0@ffornicario>
CORE SDI
http://www.core-sdi.com
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.com/bid/2347
http://www.securityfocus.com.com/bid/2222
http://www.securityfocus.com.com/bid/2117
http://www.securityfocus.com.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 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 -------------------
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 ciphertext
of size SSH_BLOCKSIZE and each of them is checked against the
others to verify that different packets dont 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
behaviours 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 behaviour and are thus vulnerable.
Systems which have the older behaviour 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 choosen 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) 2000 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.
$Id: SSH1-deattack-advisory.txt,v 1.9 2001/02/08 22:46:53 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@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@core-sdi.com
(6069944) --------------------------------(Ombruten)
Kommentar i text 6070012 av art
Kommentar i text 6070268 av MeTa, (elak)
Kommentar i text 6070724 av Kent Engström <kent@unit.liu.se>