This just came up on Bugtraq.
> Date: Sat, 13 Nov 1999 10:46:51 -0800
> From: Blue Boar <[EMAIL PROTECTED]>
> Subject: ssh-1.2.27 remote buffer overflow - exploitable (VD#7)
> To: [EMAIL PROTECTED]
>
>
> 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: <[EMAIL PROTECTED]>
>
> 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: <[EMAIL PROTECTED]>
>
> <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: <[EMAIL PROTECTED]>
>
> <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&[EMAIL PROTECTED]
>
> -------------------------------------------------------------------
>
> 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: <[EMAIL PROTECTED]>
>
> 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.
--
-- v --
[EMAIL PROTECTED]
