Date: Sun, 14 Nov 1999 13:40:51 -0500 (EST) From: Robert Watson <robert@cyrus.watson.org> To: Mike Tancsa <mike@sentex.net> Cc: freebsd-security@freebsd.org, security-officer@freebsd.org Subject: Re: Fwd: ssh-1.2.27 remote buffer overflow - exploitable (VD#7) Message-ID: <Pine.BSF.3.96.991114133831.48981B-100000@fledge.watson.org> In-Reply-To: <4.1.19991114000355.04d7f230@granite.sentex.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
I've started switching my machines to OpenSSH -- however, our port specifically disables K4 and AFS support :-). If I have time over the next few days (unlikely, traveling to Albuquerque for a DARPA conference), I'll mail in some patches to get K4 working. Otherwise, OpenSSH port seemed to work out of the box for me -- the one other change I made was to enable X forwarding in the ssh server. My feeling is disabling it in the client is far more useful, as it's the client giving out access to its display, not the server :-). so, when the RSA patent runs out, will we be disabling the US_RESIDENT in /etc/make.conf making use of RSAREF? I'm told RSAREF is substantially slower than the OpenSSL implementation, but haven't checked. On Sun, 14 Nov 1999, Mike Tancsa wrote: > > Is there a patch to this ? Or is openssh the way to go ? > > ---Mike > > > >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> > > > ><SNIP> > >Debian is immune for the (somewhat messy) reasons that they do not link > >ssh to rsaref, last time that I checked. > ><SNIP> > > > >------------------------------------------------------------------- > > > >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> > > > ><SNIP> > >And here's a patch. Not tested, as I don't use the rsaref glue on any > >machine here. > ><SNIP> > > > >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. > > ********************************************************************** > Mike Tancsa, Network Admin * mike@sentex.net > Sentex Communications Corp, * http://www.sentex.net/mike > Cambridge, Ontario * 01.519.651.3400 > Canada * > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.991114133831.48981B-100000>