Date: Thu, 15 Jan 2009 10:43:35 -0600 From: Brooks Davis <brooks@freebsd.org> To: Arnar Mar Sig <antab@valka.is> Cc: freebsd-security@freebsd.org, Jaakko Heinonen <jh@saunalahti.fi> Subject: Re: [patch] libc Berkeley DB information leak Message-ID: <20090115164335.GA80376@lor.one-eyed-alien.net> In-Reply-To: <CDEBF2A8-1971-400C-A96B-7C84D6A618CF@valka.is> References: <20090115144459.GA3154@a91-153-125-115.elisa-laajakaista.fi> <CDEBF2A8-1971-400C-A96B-7C84D6A618CF@valka.is>
next in thread | previous in thread | raw e-mail | index | archive | help
--Dxnq1zWXvFF0Q93v Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 15, 2009 at 05:21:42PM +0100, Arnar Mar Sig wrote: > Would it not be better to remove the PURITY define all together and alway= s=20 > have the memset()'s there or changing the malloc()s to calloc() if there = is=20 > no special reason for the 0xFF in memset. >=20 > Can anyone say they would rather have the possibility of sensitive=20 > information leek from every app using dbopen versus the small speed down= =20 > from always having the memset? Given that people who care about performance are almost certaintly using on= e of the newer BDB release from ports, this seems logical to me. -- Brooks > Greets > Arnar Mar Sig > Valka ehf >=20 > On Jan 15, 2009, at 3:45 PM, Jaakko Heinonen wrote: >=20 >>=20 >> Hi, >>=20 >> 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. >>=20 >> You can use this simple test program to reproduce the behavior: >>=20 >> http://www.saunalahti.fi/~jh3/dbtest.c >>=20 >> 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.) >>=20 >> This has been reported as PR 123529 >> (http://www.freebsd.org/cgi/query-pr.cgi?pr=3D123529) 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. >>=20 >> 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: >>=20 >> %%% >> Index: lib/libc/db/hash/hash_buf.c >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> --- 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 <stddef.h> >> #include <stdio.h> >> #include <stdlib.h> >> +#include <string.h> >>=20 >> #ifdef DEBUG >> #include <assert.h> >> Index: lib/libc/db/Makefile.inc >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> --- lib/libc/db/Makefile.inc (revision 187214) >> +++ lib/libc/db/Makefile.inc (working copy) >> @@ -3,6 +3,8 @@ >> # >> CFLAGS+=3D-D__DBINTERFACE_PRIVATE >>=20 >> +CFLAGS+=3D-DPURIFY >> + >> .include "${.CURDIR}/db/btree/Makefile.inc" >> .include "${.CURDIR}/db/db/Makefile.inc" >> .include "${.CURDIR}/db/hash/Makefile.inc" >> %%% >>=20 >> Could someone consider committing this or some other fix for the >> problem? >>=20 >> --=20 >> Jaakko >> _______________________________________________ >> freebsd-security@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-security >> To unsubscribe, send any mail to=20 >> "freebsd-security-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.or= g" >=20 --Dxnq1zWXvFF0Q93v Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iD8DBQFJb2e3XY6L6fI4GtQRAlGXAKCE/Cxtzq6MSd+Uijd7R4OOPwmlgwCgga9R RhnFuVVQhQh6f4lzIb0maww= =hRmG -----END PGP SIGNATURE----- --Dxnq1zWXvFF0Q93v--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090115164335.GA80376>