From owner-freebsd-security Fri Dec 10 20:11:16 1999 Delivered-To: freebsd-security@freebsd.org Received: from sand2.sentex.ca (sand2.sentex.ca [209.167.248.3]) by hub.freebsd.org (Postfix) with ESMTP id 9E91914F02; Fri, 10 Dec 1999 20:11:12 -0800 (PST) (envelope-from mike@sentex.net) Received: from gravel (ospf-mdt.sentex.net [205.211.164.81]) by sand2.sentex.ca (8.8.8/8.8.8) with SMTP id XAA03064; Fri, 10 Dec 1999 23:13:37 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <4.1.19991210230845.03a92100@granite.sentex.ca> X-Sender: mdtancsa@granite.sentex.ca X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Fri, 10 Dec 1999 23:11:06 -0500 To: Kris Kennaway From: Mike Tancsa Subject: RSAREF updated patch (was Re: Security Advisory: Buffer overflow in RSAREF2 (fwd)) Cc: security@FreeBSD.ORG In-Reply-To: References: <4.2.0.58.19991210182710.03d98d80@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 08:29 PM 12/10/99 , Kris Kennaway wrote: >On Fri, 10 Dec 1999, Brett Glass wrote: > >> Has the RSAREF port for 2.2.8 been updated? > >The RSAREF port has been updated, yes. This is how recompiling the port >fixed this gentleman's problem. There seems to be another update posted to BUGTRAQ around this issue. Here is part of the post. ---Mike >Reply-To: Gerardo Richarte >Sender: Bugtraq List >From: Gerardo Richarte >Organization: Core-SDI, Buenos Aires, Argentina >Subject: RSAREF2 buffer overflow patch >X-To: BUGTRAQ@SECURITYFOCUS.COM >To: BUGTRAQ@SECURITYFOCUS.COM >X-UIDL: 8cb69387584ce4618f845d89aaa324df > > While exchanging emails with CERT about the problem in RSAREF2 they >told me that somebody anonymous observed that there may be problem on >the >patch we released for RSAREF2. Together we produced a new version of >this >patch, which you can find in >ftp://www.core-sdi.com/pub/patches/rsaref2.patch >or at the end of this email. > While we [Core SDI S.A.] and the CERT are not aware of any exploit >that bypasses >the checks performed by the previous version, this new version is more >strict than the >other, so we recommend you to use it. > We still think that RSAREF's problem need to be solved a little >better that with a >patch, but still this is more than what we can legally do... while it's >obligatory to use >RSAREF [only] in the USA, nobody can legally alter its sources, so be >careful when >changing them. > > richie > >PS: You must apply this new patch to the original version of rsa.c. > >--------------------------------------- rsaref2.patch >*** rsa.original.c Fri Mar 26 14:01:48 1994 >--- rsa.c Fri Dec 10 12:56:34 1999 >*************** >*** 33,38 **** >--- 33,41 ---- > unsigned char byte, pkcsBlock[MAX_RSA_MODULUS_LEN]; > unsigned int i, modulusLen; > >+ if (publicKey->bits > MAX_RSA_MODULUS_BITS) >+ return (RE_LEN); >+ > modulusLen = (publicKey->bits + 7) / 8; > if (inputLen + 11 > modulusLen) > return (RE_LEN); >*************** >*** 78,83 **** >--- 81,89 ---- > unsigned char pkcsBlock[MAX_RSA_MODULUS_LEN]; > unsigned int i, modulusLen, pkcsBlockLen; > >+ if (publicKey->bits > MAX_RSA_MODULUS_BITS) >+ return (RE_LEN); >+ > modulusLen = (publicKey->bits + 7) / 8; > if (inputLen > modulusLen) > return (RE_LEN); >*************** >*** 128,133 **** >--- 134,142 ---- > int status; > unsigned char pkcsBlock[MAX_RSA_MODULUS_LEN]; > unsigned int i, modulusLen; >+ >+ if (privateKey->bits > MAX_RSA_MODULUS_BITS) >+ return (RE_LEN); > > modulusLen = (privateKey->bits + 7) / 8; > if (inputLen + 11 > modulusLen) >*************** >*** 168,173 **** >--- 177,185 ---- > unsigned char pkcsBlock[MAX_RSA_MODULUS_LEN]; > unsigned int i, modulusLen, pkcsBlockLen; > >+ if (privateKey->bits > MAX_RSA_MODULUS_BITS) >+ return (RE_LEN); >+ > modulusLen = (privateKey->bits + 7) / 8; > if (inputLen > modulusLen) > return (RE_LEN); > > >-- >A390 1BBA 2C58 D679 5A71 - 86F9 404F 4B53 3944 C2D0 >Investigacion y Desarrollo - CoreLabs - Core SDI >http://www.core-sdi.com ********************************************************************** Mike Tancsa * mike@sentex.net Sentex Communications Corp, * http://www.sentex.net/mike Cambridge, Ontario * 519 651 3400 Canada * To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message