Bug 4457

Summary: libgdbm writes out uninitialized memory buffers to files, potentially revealing sensitive information.
Product: [Retired] Red Hat Linux Reporter: Sam Varshavchik <mrsam>
Component: gdbmAssignee: David Lawrence <dkl>
Status: CLOSED NEXTRELEASE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 6.0Keywords: Security
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 1999-08-10 15:04:52 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Sam Varshavchik 1999-08-10 05:12:30 UTC 
Looks like the libgdbm allocates dynamic memory, then writes
it out to the GDBM file without fully initializing the
entire memory buffer.  Observe:

#include        <gdbm.h>
#include        <stdlib.h>

int main()
{
GDBM_FILE g;
char    *foo;
int     i;

        foo=malloc(8192);
        for (i=0; i<8192; i++)
                foo[i]= "secret"[i % 6];
        free(foo);
        g=gdbm_open("foo.dat", 0, GDBM_WRCREAT, 0644, 0);
        gdbm_close(g);
}


Link this with -lgdbm, and run it.  Afterwards, examine
foo.dat.  It should have "secret" splattered all over it.
This was tested with gdbm-1.7.3-19 and glibc-2.1.1-6. All
versions of Red Hat are probably vulnerable.

There are security implications here.  If your app handles
sensitive information, like passwords, in dynamic memory,
and then frees it, and if the freed memory is recycled and
allocated by libgdbm, your sensitive information can end up
being splattered in unused portions of your GDBM files.

Earlier this year MS got reamed for doing the same thing
with some Office files.

I ran some tests, it appears that libdb and libdb1 are not
vulnerable to the same problem.
Comment 1 Jeff Johnson 1999-08-10 15:04:59 UTC 
Fixed in gdbm-1.8.0-2. The header (block 0) was not initializing
memory to 0.