Bug 4457 - libgdbm writes out uninitialized memory buffers to files, potentially revealing sensitive information.
libgdbm writes out uninitialized memory buffers to files, potentially reveali...
Status: CLOSED NEXTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: gdbm (Show other bugs)
6.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: David Lawrence
: Security
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 1999-08-10 01:12 EDT by Sam Varshavchik
Modified: 2008-05-01 11:37 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 1999-08-10 11:04:52 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Sam Varshavchik 1999-08-10 01:12:30 EDT
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 11:04:59 EDT
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.