From owner-freebsd-security@FreeBSD.ORG Thu Jan 15 16:41:34 2009 Return-Path: Delivered-To: freebsd-security@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2D5961065675 for ; Thu, 15 Jan 2009 16:41:34 +0000 (UTC) (envelope-from antab@valka.is) Received: from smtp-vbr19.xs4all.nl (smtp-vbr19.xs4all.nl [194.109.24.39]) by mx1.freebsd.org (Postfix) with ESMTP id A5AA28FC18 for ; Thu, 15 Jan 2009 16:41:33 +0000 (UTC) (envelope-from antab@valka.is) Received: from dumb.farm.antab.is (farm.antab.is [80.101.60.195]) by smtp-vbr19.xs4all.nl (8.13.8/8.13.8) with ESMTP id n0FGLlUI017103; Thu, 15 Jan 2009 17:21:48 +0100 (CET) (envelope-from antab@valka.is) Message-Id: From: Arnar Mar Sig To: Jaakko Heinonen In-Reply-To: <20090115144459.GA3154@a91-153-125-115.elisa-laajakaista.fi> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 15 Jan 2009 17:21:42 +0100 References: <20090115144459.GA3154@a91-153-125-115.elisa-laajakaista.fi> X-Mailer: Apple Mail (2.930.3) X-Virus-Scanned: by XS4ALL Virus Scanner Cc: freebsd-security@FreeBSD.org Subject: Re: [patch] libc Berkeley DB information leak X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2009 16:41:34 -0000 Would it not be better to remove the PURITY define all together and always have the memset()'s there or changing the malloc()s to calloc() if there is no special reason for the 0xFF in memset. Can anyone say they would rather have the possibility of sensitive information leek from every app using dbopen versus the small speed down from always having the memset? Greets Arnar Mar Sig Valka ehf On Jan 15, 2009, at 3:45 PM, Jaakko Heinonen wrote: > > Hi, > > FreeBSD libc Berkeley DB can leak sensitive information to database > files. The problem is that it writes uninitialized memory obtained > from > malloc(3) to database files. > > You can use this simple test program to reproduce the behavior: > > http://www.saunalahti.fi/~jh3/dbtest.c > > Run the program and see the resulting test.db file which will > contain a > sequence of 0xa5 bytes directly from malloc(3). (See malloc(3) manual > page for the explanation for the "J" flag if you need more > information.) > > This has been reported as PR 123529 > (http://www.freebsd.org/cgi/query-pr.cgi?pr=123529) which contains a > real information leak case. The PR is assigned to secteam and I have > also personally reported it to secteam but I haven't heard a word from > secteam members. > > A code to initialize malloc'd memory exists but the feature must be > enabled with PURIFY macro. With following patch applied > the test program doesn't output 0xa5 bytes to the database file: > > %%% > Index: lib/libc/db/hash/hash_buf.c > =================================================================== > --- lib/libc/db/hash/hash_buf.c (revision 187214) > +++ lib/libc/db/hash/hash_buf.c (working copy) > @@ -57,6 +57,7 @@ __FBSDID("$FreeBSD$"); > #include > #include > #include > +#include > > #ifdef DEBUG > #include > Index: lib/libc/db/Makefile.inc > =================================================================== > --- lib/libc/db/Makefile.inc (revision 187214) > +++ lib/libc/db/Makefile.inc (working copy) > @@ -3,6 +3,8 @@ > # > CFLAGS+=-D__DBINTERFACE_PRIVATE > > +CFLAGS+=-DPURIFY > + > .include "${.CURDIR}/db/btree/Makefile.inc" > .include "${.CURDIR}/db/db/Makefile.inc" > .include "${.CURDIR}/db/hash/Makefile.inc" > %%% > > Could someone consider committing this or some other fix for the > problem? > > -- > Jaakko > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org > "