Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 15 Jan 2009 17:21:42 +0100
From:      Arnar Mar Sig <antab@valka.is>
To:        Jaakko Heinonen <jh@saunalahti.fi>
Cc:        freebsd-security@FreeBSD.org
Subject:   Re: [patch] libc Berkeley DB information leak
Message-ID:  <CDEBF2A8-1971-400C-A96B-7C84D6A618CF@valka.is>
In-Reply-To: <20090115144459.GA3154@a91-153-125-115.elisa-laajakaista.fi>
References:  <20090115144459.GA3154@a91-153-125-115.elisa-laajakaista.fi>

next in thread | previous in thread | raw e-mail | index | archive | help
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 <stddef.h>
> #include <stdio.h>
> #include <stdlib.h>
> +#include <string.h>
>
> #ifdef DEBUG
> #include <assert.h>
> 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 
> "



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CDEBF2A8-1971-400C-A96B-7C84D6A618CF>