Date: Sun, 14 Nov 1999 00:08:12 -0500 From: Mike Tancsa <mike@sentex.net> To: freebsd-security@freebsd.org Cc: security-officer@freebsd.org Subject: Fwd: ssh-1.2.27 remote buffer overflow - exploitable (VD#7) Message-ID: <4.1.19991114000355.04d7f230@granite.sentex.ca>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4.1.19991114000355.04d7f230>