[12615] in bugtraq
Re: ssh-1.2.27 remote buffer overflow - exploitable (VD#7)
daemon@ATHENA.MIT.EDU (Jochen Bauer)
Wed Nov 17 12:17:45 1999
Mail-Followup-To: BUGTRAQ@SECURITYFOCUS.COM
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-md5;
protocol="application/pgp-signature"; boundary="sm4nu43k4a2Rpi4c"
Message-Id: <19991116204836.A16269@luna.theo2.physik.uni-stuttgart.de>
Date: Tue, 16 Nov 1999 20:48:36 +0100
Reply-To: Jochen Bauer <jtb@THEO2.PHYSIK.UNI-STUTTGART.DE>
From: Jochen Bauer <jtb@THEO2.PHYSIK.UNI-STUTTGART.DE>
X-To: BUGTRAQ@SECURITYFOCUS.COM
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <03so26g24n.fsf@colargol.tihlde.hist.no>
--sm4nu43k4a2Rpi4c
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
On Tue, Nov 16, 1999 at 11:30:16AM +0100, Oystein Viggen wrote:
> Blue Boar wrote:
>=20
> > <SNIP>
> > Debian is immune for the (somewhat messy) reasons that they do not link
> > ssh to rsaref, last time that I checked.
> > <SNIP>
>=20
> Does the fact that the international version of ssh from replay.com uses
> "internal rsaref" instead of the "external rsaref" in the US version make
> it immune to this attack too?
>=20
> The version is at least not as far as I can see externally linked to any
> rsaref library:
[...]
As the buffer overflow is not located in the rsaref library itself, one
cannot say that a particular version of sshd is vulnerable or not just
because of the libraries it has been linked with.=20
The start of all trouble is in rsaglue.c, where a pointer to the fixed
length buffer input_data[MAX_RSA_MODULUS_LEN] in the function
rsa_private_decrypt is passed to gmp_to_rsaref. However, this piece of
code is only compiled in when "RSAREF" is defined during compilation time
(preprocessing time, to be precise), as it first deals with the conversion
of the encrypted session key from multiple precision integer format to=20
some kind of format expected by the rsaref library functions before calling=
=20
the actual decryption routine. The overflow then occurs in mpaux.c in the=
=20
function "mp_linearize_msb_first".
If "RSAREF" is not defined because the rsaref library functions are not
used, the function "rsa_private_decrypt" compiled in in this case does not
make use of such a fixed length buffer. =20
So, in summary one may say that if a binary is linked with a RSA=20
implematation that uses the same interface as rsaref, the=20
"rsa_private_decrypt" function which handles the conversion from multiple
precision integer to the "rsaref" format and uses the fixed length buffer
input_data[MAX_RSA_MODULUS_LEN] is compiled in, and therefore i expect
it to be vulnerable. =20
--
Jochen Bauer
RUS Security Team (RUS-CERT) =
=20
Computer Center of the University of Stuttgart =20
Germany
=20
************************************************************************=20
*Email: jtb@theo2.physik.uni-stuttgart.de *
* jochen.bauer@rus.uni-stuttgart.de *
* *
*PGP Public Key: *
*http://ca.uni-stuttgart.de:11371/pks/lookup?op=3Dindex&search=3D0xB5D92889*
************************************************************************=20
--sm4nu43k4a2Rpi4c
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
iQEVAwUBODG1E1thq5K12SiJAQFxwAf/Q8nIvwtRSzd4SUi3xzAAHlg3A+4pTKRU
ief+SeHWEFNyTRpbuhrBYicNTep2xl09O5qmu23RNiflIQZgfc+jlVvQQafafbIx
xh4XlAcpVvB3TyAPXqH2AShkzxvsMSSbOwP31Pp39jtZvTL3XxLvzPEXuh36LtQA
Eh02u20oqjjcR3saqRbtelZESGTYOf5fBqvGnJbCDUAr2goccAFBGNB+kE4eE4Nk
eqcC4q4zYEGgZw/6YbmP6BqsS3Xi2YXrOVsyfawE5HGFlGJLn42bVcDcCI57ycqW
PkvNK0HldhfHz+fu8PBDZ1XZ4TBy4J60pL3hkWY/WpzgjXvGqBEA7A==
=pL39
-----END PGP SIGNATURE-----
--sm4nu43k4a2Rpi4c--
