just that u guys know, there's a vulnerability in ssh protocol 1.5... was found
sumtime tuesday/wednsday this week... here's some info for ya on the ssh1 vulnerability
Recommendation: Run OpenSSH 2.3.0 (2.3.0p1) but dont use devel version
2.3.1, its got other vulnerabilities...
If you are running a commercial version of SSH, turn off
protocol 1 support.
during last night and today there are some rumours that there is also a vulnerability
in 2.3.0 .. but i havnt seen it 100% confirmed yet....
cheers,
dennison
> 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
> [EMAIL PROTECTED] 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 : [EMAIL PROTECTED]
> 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 [EMAIL PROTECTED]
__________________________________
www.edsamail.com
_
Philippine Linux Users Group. Web site and archives at http://plug.linux.org.ph
To leave: send "unsubscribe" in the body to [EMAIL PROTECTED]
