Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 4457 - libgdbm writes out uninitialized memory buffers to files, potentially revealing sensitive information.
Summary: libgdbm writes out uninitialized memory buffers to files, potentially reveali...
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: gdbm
Version: 6.0
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: David Lawrence
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 1999-08-10 05:12 UTC by Sam Varshavchik
Modified: 2008-05-01 15:37 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 1999-08-10 15:04:52 UTC

Attachments (Terms of Use)

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()
char    *foo;
int     i;

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

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.

Note You need to log in before you can comment on or make changes to this bug.