Gerardo Richarte <[EMAIL PROTECTED]> of CORE-SDI (Seguridad de la
Informacion), the Bugtraq-es team which just published an Advisory about a
buffer overrun vulnerability in RSAREF v.2, asked me to pass this
additional comment along to the OpenSSL-users list. I'm also going to also
bounce it to the SSH-users list in Finland.
Please note that the RSAREFv.2 libraries were built around RSADSI's
BSAFE v.1. RSA's current toolkit is BSAFE 4.3 -- so the freeware RSAREF
implementation is seven or eight generations behind the current distribution
set used in RSA's commercial crypto sales in the US and abroad.
I don't want to throw up any FUD, but it is unlikely that this is
the only user-interface problem or other issue of praxis in RSAREF v.2, a
venerable freeware distribution which a lot of people learned from -- but
one which RSAS, the <ahem> US patent owner, does not and will not support
in 1999.
RSAREF was a free RSA crypto library intended for internal
(non-revenue-producing) testbeds in US firms, academic study, and
professional and amateur research into RSApkc implementation models. RSAREF
was not intended for a production environment. (For the curious, Tom
Dunigan of ORNL has the RSAREF-2.0 agreement and license online at:
<http://www.epm.ornl.gov/~dunigan/rsaref.txt>)
The range of the RSAREF implementations available to the licensee
was restricted by the RSAREF license to only those functions explicitly
enabled by the published RSAREF interface -- and those functions do not
include SSL. RSAREF is a grand old lady, but it is also slow (probably
intentionally), and it lacks a lot of functionality, ciphers, (and config
checks!) which ship in modern commercial-grade crypto libraries.
That said -- to the extent that RSAREF is still being used as a
crypto library for SSLeay/OpenSSL and SSHv.1 "testbed implementations," in
the US and elsewhere (?!) -- would not it be easier and safer to address
this sort of potential problem with a wrapper which checks for appropriate
input, and flags or blocks unruly exceptions?
Suerte,
_Vin
[Obligatory disclaimer: The Privacy Guild has for years done consulting for
RSAS -- but, obviously, only RSAS speaks for RSA Security, Inc.]
---------------------------------------------------------
Date: Thu, 02 Dec 1999 14:09:13 -0300
From: Gerardo Richarte <[EMAIL PROTECTED]>
Re: Buffer overflow in RSAREF2, Security Advisory (CORE SDI)
A note on OpenSSL:
We know that application developed with SSLeay AND OpenSSL has this problem
when linked with RSAREF2. I checked both codes yesterday. I was waiting till
today (I wanted to sleep) to tell you, the problem is not this libraries, as
you surely understand, and I personally think that is not you task to triple
check the arguments you pass along to RSAREF2, BUT as (as what I know)
RSAREF2 cannot be modified by third parties, and RSA S. Inc.
do not support it any more, this may be the only legal solution.
So, in my opinion you should take a look at our patch for RSAREF2, and
'port' it to your lib, even when that is not the best solution: This patch
is only a patch, and we all (the people at Core) agree that RSAREF2's
source code need a mayor change, as almost everywhere it uses user supplied
buffer's length with its fixed size buffers allocated in the stack... but
theres nothing we can do, unless they release the source code, or expires
the patent.
If you need any help we what to do, just mail me, I'll be glad to help with
this. And if anybody thinks that there is anybody else that needs to know
this, just forward him this mail and point him to me. Do you know if SSLeay
is still mantained? I think that they would like to get this email too.
Ok, that's it.
richie
PS: Note the 'perfect-automagic-wrapping' of this email! (-:
--
A390 1BBA 2C58 D679 5A71 - 86F9 404F 4B53 3944 C2D0
Investigacion y Desarrollo - CoreLabs - Core SDI
http://www.core-sdi.com
