Date: Sun, 14 Nov 1999 14:13:46 -0500 (EST) From: Brian Fundakowski Feldman <green@FreeBSD.org> To: Robert Watson <robert+freebsd@cyrus.watson.org> Cc: Mike Tancsa <mike@sentex.net>, freebsd-security@freebsd.org Subject: Re: Fwd: ssh-1.2.27 remote buffer overflow - exploitable (VD#7) Message-ID: <Pine.BSF.4.10.9911141408270.45793-100000@green.myip.org> In-Reply-To: <Pine.BSF.3.96.991114133831.48981B-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 14 Nov 1999, Robert Watson wrote: > > 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 :-). I have AFS and K4 ?= NO there because I don't have a way to test them, and they rely on other sources not in the base (lots to download if you're not going to use them, so it would be senseless to make them mandatory.) S/KEY I haven't enabled yet because, frankly, I've never used it. The port doesn't actually DISABLE them, just doesn't have the hooks to enable them from the port framework yet. I'll commit your patches as long as they do exactly what they should, bar cleanups. > > 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. I don't see any reason not to :) When the patent runs out, I'll be happy. > > 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 > -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / green@FreeBSD.org `------------------------------' 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.4.10.9911141408270.45793-100000>