[12571] in bugtraq
ssh-1.2.27 remote buffer overflow - exploitable (VD#7)
daemon@ATHENA.MIT.EDU (Blue Boar)
Sat Nov 13 22:05:53 1999
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <382DB21B.CB92D7A0@thievco.com>
Date: Sat, 13 Nov 1999 10:46:51 -0800
Reply-To: Blue Boar <BlueBoar@THIEVCO.COM>
From: Blue Boar <BlueBoar@THIEVCO.COM>
X-To: bugtraq@securityfocus.com
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>
<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.
