From dittrich@cac.washington.edu Mon Dec 6 17:15:35 1999 Received: from mxu4.u.washington.edu (mxu4.u.washington.edu [140.142.33.8]) by lists.u.washington.edu (8.9.3+UW99.09/8.9.3+UW99.09) with ESMTP id RAA70886; Mon, 6 Dec 1999 17:15:33 -0800 Received: from red3.cac.washington.edu (5356@red3.cac.washington.edu [140.142.55.7]) by mxu4.u.washington.edu (8.9.3+UW99.09/8.9.3+UW99.08) with ESMTP id RAA23720; Mon, 6 Dec 1999 17:15:33 -0800 Received: from localhost (dittrich@localhost) by red3.cac.washington.edu (8.9.3+UW99.09/8.9.3+UW99.08) with ESMTP id RAA10412; Mon, 6 Dec 1999 17:15:30 -0800 Date: Mon, 6 Dec 1999 17:15:29 -0800 (PST) From: Dave Dittrich To: Network System Adminstrators list , linux@u.washington.edu cc: LAN Administrators list Subject: Two buffer overflow bugs in SSH version 1.2.X w/RSAREF Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII For the past month, there has been discussion on various security email lists of buffer overflow bugs (now two of them) in the RSAREF library, found in conjunction with use of rsaglue.c in SSH version 1.2.27. ("RSAREF" is the RSA reference library for encryption/decryption using the RSA algorithms, which are patented and require licenses to use until the patent expires in September of 2000). These bugs will be present (although not immediately exploitable) in any program linked against RSAREF, most notably SSH, but also various other servers like web servers, etc. -- see below for details).` It should be noted that the default is to NOT USE RSAREF in SSH version 1.2.X, which means that it appears that unless you explicitly go out and get the RSAREF libraries (and presumably pay your license fee to use them), you will NOT be vulnerable to these bugs. Please read the details of these discussions below to be sure you understand where the bugs are, and to see/get the patches you will need to fix this IF YOU USE RSAREF. (RSA says they are not maintaining this code, so they will not be fixing it.) C&C will be making sure that none of our systems are compiled to use RSAREF, and anyone using SSH in your department should also verify that your server is not compiled with RSAREF. I am not sure how to test remotely to see if a given server is compiled with/without RSAREF, but I believe you can infer this on systems where you compiled both SSH clients and server by using "ssh -v" like this: C shell: % ssh -v |& grep RSAREF Standard version. Does not use RSAREF. <== Not Vulnerable. % ssh -v |& grep RSAREF Compiled with RSAREF. <== Danger, Will Robinson! Bourne shell: $ ssh -v 2>&1 | grep RSAREF Standard version. Does not use RSAREF. -- Dave Dittrich Client Services dittrich@cac.washington.edu Computing & Communications University of Washington Dave Dittrich / dittrich@cac.washington.edu [PGP Key] PGP 6.5.1 key fingerprint: FE 97 0C 57 08 43 F3 EB 49 A1 0C D0 8E 0C D0 BE C8 38 CC B5 ---------- Forwarded message ---------- Date: Sat, 13 Nov 1999 10:46:51 -0800 Subject: ssh-1.2.27 remote buffer overflow - exploitable (VD#7) From: Blue Boar To: BUGTRAQ@SECURITYFOCUS.COM ------------------------------------------------------------------- Periodically, the moderator of of the vuln-dev mailing list will post summaries of issues discussed there to Bugtraq and possibly other relevant lists. This will usually happen when an issue has been resolved, or it appears that there will be no further discussion on vuln-dev. Each separate issue will be given it's own posting to facilitate referencing them separately, for discussion, forwarding, or appearance in vulnerability databases. To subscribe to vuln-dev, send an e-mail to listserv@securityfocus.com, with SUBSCRIBE VULN-DEV in the body of the message. A FAQ and archive can be found at www.securityfocus.com-->forums-->vuln-dev (click on these sections, the web pages are forms-based.) ------------------------------------------------------------------- There appears to be a serious vulnerability in ssh 1.2.27. I will let the folks who worked on this issue describe. There was brief discussion on vuln-dev on the politics of ssh 1 vs. ssh 2, etc... you may or may not want to play that out on Bugtraq. One of the key points of the SSH 1 vs. SSH 2 debate is regarding licensing. Basically, because of a less strict license on SSH 1, more folks are likely to be running that version. (This is all referring to the Datafellows implementation that everyone uses, rather than standards and protocols, I presume.) As usually, check the vuln-dev archives if you want the full story. This isn't necessarily a dead topic there yet, but this issue should get out there sooner rather than later. BB ------------------------------------------------------------------- To: Exploit-Dev Subject: ssh-1.2.27 remote buffer overflow - exploitable Date: Mon Nov 08 1999 16:48:53 Author: Frank Message-ID: <19991109014853.3239.qmail@securityfocus.com> This is submitted to the Freebsd bug tracking system, although there are doubtless other vendors who leave this package, despite the existence of the ssh-2.X. While Debian appears to be immune, I was able to crash my ssh daemon (much to my dismay), and there appears the potential to execute arbitrary code, as long as you encrypt it first... Here is the freebsd report.. it describes the method to crash a remote Ssh daemon (lets hope you ran sshd from your xinetd, etc). http://www.freebsd.org/cgi/query-pr.cgi?pr=14749 ------------------------------------------------------------------- To: Exploit-Dev Subject: Re: ssh-1.2.27 remote buffer overflow - exploitable Date: Mon Nov 08 1999 21:04:19 Author: Daniel Jacobowitz Message-ID: <19991109110419.A29502@drow.res.cmu.edu> Debian is immune for the (somewhat messy) reasons that they do not link ssh to rsaref, last time that I checked. ------------------------------------------------------------------- To: Exploit-Dev Subject: Re: ssh-1.2.27 remote buffer overflow - exploitable Date: Mon Nov 08 1999 21:24:17 Author: Daniel Jacobowitz Message-ID: <19991109112417.A30046@drow.res.cmu.edu> And here's a patch. Not tested, as I don't use the rsaref glue on any machine here. Ed: Patch can be found at: http://www.securityfocus.com/templates/archive.pike?list=82&date=1999-11-08&msg=19991109112417.A30046@drow.res.cmu.edu ------------------------------------------------------------------- To: Exploit-Dev Subject: Re: ssh-1.2.27 remote buffer overflow - exploitable Date: Tue Nov 09 1999 04:42:16 Author: Jochen Bauer Message-ID: <19991109124216.A28812@luna.theo2.physik.uni-stuttgart.de> I've taken a closer look at the problem. Here's my analysis: In sshd.c, around line 1513 the client-generated session key, that has been encrypted with the server and host public keys, is received from the client as a multiple precision integer. /* Get the encrypted integer. */ mpz_init(&session_key_int); packet_get_mp_int(&session_key_int); The encrypted session key is then (around line 1525) passed to rsa_private_decrypt to do the first part of the decryption, which is either decryption using the server private key or decryption using the host private key, depending on which key has the larger modulus. rsa_private_decrypt(&session_key_int, &session_key_int, &sensitive_data.private_key); If RSAREF is used (i.e. RSAREF is defined in the code), the rsa_private_decrypt function in rsaglue.c (around line 162) looks like: void rsa_private_decrypt(MP_INT *output, MP_INT *input, RSAPrivateKey *key) { unsigned char input_data[MAX_RSA_MODULUS_LEN]; unsigned char output_data[MAX_RSA_MODULUS_LEN] unsigned int input_len, output_len, input_bits; [...] input_bits = mpz_sizeinbase(input, 2); input_len = (input_bits + 7) / 8; gmp_to_rsaref(input_data, input_len, input); [...] } The trouble spot is the fixed length buffer input_data[MAX_RSA_MODULUS_LEN]. A pointer to this buffer is passed to the conversion function gmp_to_rsaref along with a pointer to the encrypted session key and the length (input_len) of the encrypted session key, which may be greater than [MAX_RSA_MODULUS_LEN]. gmp_to_rsaref (located around line 79 of rsaglue.c) simply calls mp_linearize_msb_first(buf, len, value). void gmp_to_rsaref(unsigned char *buf, unsigned int len, MP_INT *value) { mp_linearize_msb_first(buf, len, value); } mp_linearize_msb_first is contained in mpaux.c around line 41. The function looks like: void mp_linearize_msb_first(unsigned char *buf, unsigned int len, MP_INT *value) { unsigned int i; MP_INT aux; mpz_init_set(&aux, value); for (i = len; i >= 4; i -= 4) <------- { unsigned long limb = mpz_get_ui(&aux); PUT_32BIT(buf + i - 4, limb); <------- mpz_div_2exp(&aux, &aux, 32); } [...] } There's the overflow! len is the length of the encrypted session key, while buf is a pointer to the fixed length buffer input_data[MAX_RSA_MODULUS_LEN] and no check wether len is greater than MAX_RSA_MODULUS_LEN is performed. The fix should be obvious! About the possible exploit: In this particular overflow, the encrypted, client generated session key has to be taken as the exploit buffer. I.e. the shellcode, NOPs and jump address has to sent to the server instead of the encrypted session key. To make that clear: The shellcode, NOPs and jump address don't have to be encrypted as they are taken as the ENCRYPTED session key. However, the data that is finally written into the buffer are the limbs of the multiple precision integer that session_key_int is assumed to be. The exploit buffer code therefore must be converted into a multiple precision integer, which upon extraction of the limbs into the buffer yields the correct exploit buffer code. The best way would probably be to start from the exploit buffer as it should finally be to overflow the target buffer and use the functions of the GNU multiple precision integer library to reverse the procedure happening to the encrypted session key in the sshd code step be step, leading to the exploit buffer that has to be sent instead of the encrypted session key. That may be difficult, be it think it's possible. ---------- Forwarded message ---------- Date: Tue, 16 Nov 1999 20:48:36 +0100 Subject: Re: ssh-1.2.27 remote buffer overflow - exploitable (VD#7) From: Jochen Bauer To: BUGTRAQ@SECURITYFOCUS.COM On Tue, Nov 16, 1999 at 11:30:16AM +0100, Oystein Viggen wrote: > Blue Boar wrote: > > > > > Debian is immune for the (somewhat messy) reasons that they do not link > > ssh to rsaref, last time that I checked. > > > > Does the fact that the international version of ssh from replay.com uses > "internal rsaref" instead of the "external rsaref" in the US version make > it immune to this attack too? > > The version is at least not as far as I can see externally linked to any > rsaref library: [...] As the buffer overflow is not located in the rsaref library itself, one cannot say that a particular version of sshd is vulnerable or not just because of the libraries it has been linked with. The start of all trouble is in rsaglue.c, where a pointer to the fixed length buffer input_data[MAX_RSA_MODULUS_LEN] in the function rsa_private_decrypt is passed to gmp_to_rsaref. However, this piece of code is only compiled in when "RSAREF" is defined during compilation time (preprocessing time, to be precise), as it first deals with the conversion of the encrypted session key from multiple precision integer format to some kind of format expected by the rsaref library functions before calling the actual decryption routine. The overflow then occurs in mpaux.c in the function "mp_linearize_msb_first". If "RSAREF" is not defined because the rsaref library functions are not used, the function "rsa_private_decrypt" compiled in in this case does not make use of such a fixed length buffer. So, in summary one may say that if a binary is linked with a RSA implematation that uses the same interface as rsaref, the "rsa_private_decrypt" function which handles the conversion from multiple precision integer to the "rsaref" format and uses the fixed length buffer input_data[MAX_RSA_MODULUS_LEN] is compiled in, and therefore i expect it to be vulnerable. -- Jochen Bauer RUS Security Team (RUS-CERT) Computer Center of the University of Stuttgart Germany ************************************************************************ *Email: jtb@theo2.physik.uni-stuttgart.de * * jochen.bauer@rus.uni-stuttgart.de * * * *PGP Public Key: * *http://ca.uni-stuttgart.de:11371/pks/lookup?op=index&search=0xB5D92889* ************************************************************************ ---------- Forwarded message ---------- Date: Tue, 16 Nov 1999 13:54:24 -0500 Subject: Re: ssh-1.2.27 remote buffer overflow - exploitable (VD#7) From: Daniel Jacobowitz To: BUGTRAQ@SECURITYFOCUS.COM On Tue, Nov 16, 1999 at 11:30:16AM +0100, Oystein Viggen wrote: > Blue Boar wrote: > > > > > Debian is immune for the (somewhat messy) reasons that they do not link > > ssh to rsaref, last time that I checked. > > > > Does the fact that the international version of ssh from replay.com uses > "internal rsaref" instead of the "external rsaref" in the US version make > it immune to this attack too? > > The version is at least not as far as I can see externally linked to any > rsaref library: As far as I can tell from the spec file, the -5i version is never configured with --with-rsaref, and the guilty code in rsaglue.c is never reached. Dan /--------------------------------\ /--------------------------------\ | Daniel Jacobowitz |__| SCS Class of 2002 | | Debian GNU/Linux Developer __ Carnegie Mellon University | | dan@debian.org | | dmj+@andrew.cmu.edu | \--------------------------------/ \--------------------------------/ ---------- Forwarded message ---------- Date: Wed, 1 Dec 1999 23:09:12 -0300 Subject: Security Advisory: Buffer overflow in RSAREF2 From: Gerardo Richarte To: BUGTRAQ@SECURITYFOCUS.COM -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - ------------------------------------------------------------------------ CORE SDI S.A. Buenos Aires, Argentina CORE SDI Security Advisory December 1st., 1999 Buffer overflow in RSAREF2 - ------------------------------------------------------------------------- While researching the exploitability of a buffer overflow in SSH up to version 1.2.27, we discovered a second buffer overflow in the implmementation of the RSA algorithm in RSAREF2 from RSA Data Security. This advisory addresses the details of the bug discovered, the details are somewhat focused on the ability to exploit the bug in SSH compiled with RSAREF2, but its extensible to any software product that uses RSAREF2 Problem description ~~~~~~~~~~~~~~~~~~~~ RSAREF2 API exports 4 functions in rsa.c: int RSAPublicEncrypt() int RSAPrivateEncrypt() int RSAPublicDecrypt() int RSAPrivateDecrypt() The 4 functions define a local variable pkcsBlock of fixed length MAX_RSA_MODULUS_LEN (128 bytes) In order to perform the RSA operations, the functions call the internal functions RSAPrivateBlock() and RSAPublicBlock(). RSAPrivateDecrypt() and RSAPublicDecrypt() pass a pointer to the local variable pkcsBlock to be used as the output buffer for RSAPublicBlock() and RSAPrivateBlock() respectively. The two functions then perform the RSA operations and copy the results to the output buffer using the NN_Encode() and NN_Decode() functions. Lack of strict bounds checking and proper validation of input parameters in all these functions allows an attacker to overflow the pkcsBLock variable and overwrite the stack, making it possible to execute arbitrary commands on the vulnerable system. Technical details ~~~~~~~~~~~~~~~~~ As an axample we will describe the vulnerability focusing on the decrypt operations performed in RSAREF2 based on the private key. Such operations are done with the function RSAPrivateDecrypt() defined as follows in rsa.c: /* RSA private-key decryption, according to PKCS #1. */ int RSAPrivateDecrypt (output, outputLen, input, inputLen, privateKey) unsigned char *output; /* output block */ unsigned int *outputLen; /* length of output block */ unsigned char *input; /* input block */ unsigned int inputLen; /* length of input block */ R_RSA_PRIVATE_KEY *privateKey; /* RSA private key */ { int status; unsigned char pkcsBlock[MAX_RSA_MODULUS_LEN]; unsigned int i, modulusLen, pkcsBlockLen; modulusLen = (privateKey->bits + 7) / 8; if (inputLen > modulusLen) return (RE_LEN); if (status = RSAPrivateBlock (pkcsBlock, &pkcsBlockLen, input, inputLen, privateKey)) return (status); ... return (0); } Note that inputLen is checked against a transformation of privateKey's bits field, to satisfy this constrain an attacker must alter this field in privateKey, but this, almost by miracle doesn't affect the final result. Notese que se hace una verificacion sobre la longitud del buffer de entrada, comparandola con una transformacion del campo bits de la clave privada (privateKey), para que esta validacion sea satisfecha es necesario cambiar este campo en privateKey, pero esto, casi milagrosamente no afecta al resultado de la encripcion. As we can see, RSAPrivateDecrypt() calls RSAPrivateBlock() passing pkcsBlock as the output buffer, no length checking is performed to ensure that pkcsBlock will not be overrun. RSAPrivateBLock() performs the RSA private key operations ans is define as follows: /* Raw RSA private-key operation. Output has same length as modulus. Assumes inputLen < length of modulus. Requires input < modulus. */ static int RSAPrivateBlock (output, outputLen, input, inputLen, privateKey) unsigned char *output; /* output block */ unsigned int *outputLen; /* length of output block */ unsigned char *input; /* input block */ unsigned int inputLen; /* length of input block */ R_RSA_PRIVATE_KEY *privateKey; /* RSA private key */ { NN_DIGIT c[MAX_NN_DIGITS], cP[MAX_NN_DIGITS], cQ[MAX_NN_DIGITS], dP[MAX_NN_DIGITS], dQ[MAX_NN_DIGITS], mP[MAX_NN_DIGITS], mQ[MAX_NN_DIGITS], n[MAX_NN_DIGITS], p[MAX_NN_DIGITS], q[MAX_NN_DIGITS], qInv[MAX_NN_DIGITS], t[MAX_NN_DIGITS]; unsigned int cDigits, nDigits, pDigits; NN_Decode (c, MAX_NN_DIGITS, input, inputLen); .... cDigits = NN_Digits (c, MAX_NN_DIGITS); nDigits = NN_Digits (n, MAX_NN_DIGITS); pDigits = NN_Digits (p, MAX_NN_DIGITS); /* Compute mP = cP^dP mod p and mQ = cQ^dQ mod q. (Assumes q has length at most pDigits, i.e., p > q.) */ .... /* Chinese Remainder Theorem: m = ((((mP - mQ) mod p) * qInv) mod p) * q + mQ. */ if (NN_Cmp (mP, mQ, pDigits) >= 0) NN_Sub (t, mP, mQ, pDigits); else { NN_Sub (t, mQ, mP, pDigits); NN_Sub (t, p, t, pDigits); } NN_ModMult (t, t, qInv, p, pDigits); NN_Mult (t, t, q, pDigits); NN_Add (t, t, mQ, nDigits); *outputLen = (privateKey->bits + 7) / 8; NN_Encode (output, *outputLen, t, nDigits); .... return (0); } RSAPrivateBlock() calls NN_Encode() to encode and copy the results into the output buffer (a pointer to the pkcsBlock variable in RSAPublicDecrypt() function), the length of the output buffer is calculated based on the bits field of the pivateKey structure, passed originally to RSAPublicDecrypt() and does not take into account the fixed length characteristics of the output buffer. The NN_Encode() function is defined as follows: /* Encodes b into character string a, where character string is ordered from most to least significant. Lengths: a[len], b[digits]. Assumes NN_Bits (b, digits) <= 8 * len. (Otherwise most significant digits are truncated.) */ void NN_Encode (a, len, b, digits) NN_DIGIT *b; unsigned char *a; unsigned int digits, len; { NN_DIGIT t; int j; unsigned int i, u; for (i = 0, j = len - 1; i < digits && j >= 0; i++) { t = b[i]; for (u = 0; j >= 0 && u < NN_DIGIT_BITS; j--, u += 8) a[j] = (unsigned char)(t >> u); } for (; j >= 0; j--) a[j] = 0; } NN_Encode() encodes and copies to 'a' (the output buffer, pkcsBLock) 'digits' bytes of 'b' (the results of the RSA private key operation) from the end to the start of the buffer, starting at position 'len', the modulus length of the private key passed to RSAPrivateDecrypt(). Providing a suitable modulus length to RSAPrivateDecrypt() it is possible to force NN_Encode() to copy data beyond the bounds of pkcsBLock and overwrite the return address of RSAPRivateDecrypt(), gaining control of the processor and being able to execute code located elsewhere in the vulnerable program. The exploitability of this bug in SSH comes from the fact that a bug in SSH itself discussed and published in the vuln-dev and bugtraq mailing lists, allows a remote client to provide a suitable private key to the RSAREF functions. The same problem is present in the RSAPublicDecrypt() function, and its exploitability might be even easier, since its much easier to provide a malicious public key to any software package that supports RSA and uses the RSAREF2 implementation. Impact ~~~~~~ It is possible to execute arbitrary commands as the user that runs the RSAREF2 code. For SSH up to 1.2.27 compiled with RSAREF2 this implies the remote execution of arbitrary commands as root. Fix information ~~~~~~~~~~~~~~~ RSA Security was contacted and replied that they don't support RSAREF2 anymore. For futher details you may contact John Linn A patch is provided below, please read carefully the file license.txt from the RSAREF2 distribution before applying it Vulnerable systems ~~~~~~~~~~~~~~~~~~ - - SSH up to 1.2.27 compiled with RSAREF2 (RSAREF is not compiled in by default but it's required in some cases in USA) - - Possibly any other software packages that uses RSAREF2 Additional information ~~~~~~~~~~~~~~~~~~~~~~ This vulnerability was discovered by Alberto Solino and Gerardo Richarte at Core SDI S.A. Copyright Notice: ~~~~~~~~~~~~~~~~~ The contents of this advisory are copyright (c) 1999 CORE SDI S.A. and may be distributed freely provided that no fee is charged for this distribution and proper credit is given. Fix ~~~ Copy de remining of this message to a file named rsaref.patch in rsaref2/source, and apply with 'patch MAX_RSA_MODULUS_LEN) return (RE_LEN); + modulusLen = (publicKey->bits + 7) / 8; if (inputLen + 11 > modulusLen) return (RE_LEN); @@ -78,6 +80,8 @@ unsigned char pkcsBlock[MAX_RSA_MODULUS_LEN]; unsigned int i, modulusLen, pkcsBlockLen; + if (inputLen>MAX_RSA_MODULUS_LEN) return (RE_LEN); + modulusLen = (publicKey->bits + 7) / 8; if (inputLen > modulusLen) return (RE_LEN); @@ -129,6 +133,8 @@ unsigned char pkcsBlock[MAX_RSA_MODULUS_LEN]; unsigned int i, modulusLen; + if (inputLen+3>MAX_RSA_MODULUS_LEN) return (RE_LEN); + modulusLen = (privateKey->bits + 7) / 8; if (inputLen + 11 > modulusLen) return (RE_LEN); @@ -168,6 +174,8 @@ unsigned char pkcsBlock[MAX_RSA_MODULUS_LEN]; unsigned int i, modulusLen, pkcsBlockLen; + if (inputLen>MAX_RSA_MODULUS_LEN) return (RE_LEN); + modulusLen = (privateKey->bits + 7) / 8; if (inputLen > modulusLen) return (RE_LEN); -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 5.0i for non-commercial use Charset: noconv iQA/AwUBOEXStUBPS1M5RMLQEQLf4QCg6kaXLdSnzgfbgVXztOD38MFTX7AAmwTG F9dMkpeKR3EiiuDSCwi4tNrd =NNXd -----END PGP SIGNATURE----- --- For a personal reply use gera@core-sdi.com ---------- Forwarded message ---------- Date: Thu, 2 Dec 1999 16:50:46 -0300 Subject: Re: Security Advisory: Buffer overflow in RSAREF2 From: Gerardo Richarte To: BUGTRAQ@SECURITYFOCUS.COM Gerardo Richarte wrote: > > While researching the exploitability of a buffer overflow in > SSH up to version 1.2.27, we discovered a second buffer overflow > in the implmementation of the RSA algorithm in RSAREF2 from > RSA Data Security. To make this clear: in combination with the buffer overflow in rsaglue.c this makes possible to get a remote shell on a machine running sshd AND it also makes possible to use a reverse exploit to gain access on clients' machines, using malicious sshd. richie PS: We are studding the possibility of using this buffer overflow alone, not in combination with rsaglue.c. What will make it possible to exploit it on patched ssh and sshd, and probably in OpenSSH -- A390 1BBA 2C58 D679 5A71 - 86F9 404F 4B53 3944 C2D0 Investigacion y Desarrollo - CoreLabs - Core SDI http://www.core-sdi.com --- For a personal reply use gera@core-sdi.com ---------- Forwarded message ---------- Date: Sat, 4 Dec 1999 17:45:20 -0500 Subject: Re: Security Advisory: Buffer overflow in RSAREF2 From: Niels Provos To: BUGTRAQ@SECURITYFOCUS.COM In message <3846CC26.513CE96F@core-sdi.com>, Gerardo Richarte writes: > To make this clear: in combination with the buffer overflow in rsaglue. >c this makes possible to get >a remote shell on a machine running sshd AND it also makes possible to use a r >everse exploit to gain access on >clients' machines, using malicious sshd. I fear that this posting should have been even clearer. To sum the problem up more clearly: ssh-1.2.27 (if compiled with RSAREF2) is vulnerable. Attackers can obtain a shell on the machine running sshd. The exploit uses buffer overflows in the RSAREF2 implementation AND in the rsaglue.c file in ssh-1.2.27. I am surprised that there wasnt a bigger outrage on the mailing list about this, it is quite serious!!! On the other hand, OpenSSH is not vulnerable to this remote exploit. Since rsaglue.c was rewritten, OpenSSH does stricter parameter checking than ssh-1.2.27 and these recent problems in ssh-1.2.27 did NOT affect OpenSSH. Nonetheless, OpenSSH users in the USA that use OpenSSL compiled with RSAREF2 should update their ssl library (since isakmpd or httpd may be affected), see previous postings on Bugtraq, and http://www.openbsd.org/errata.html#sslUSA Another thing is worth mentioning, RSA could use the buffer overflow in RSAREF2 to scan machines in the USA for RSA license violation. For example, sshds that do not use RSAREF2 do will behave differently than those that do. Information on OpenSSH can be found at http://www.openssh.com/ Infomration on OpenSSL can be found at http://www.openssl.org/ .