misc/124410: malloc exposes previously free'd memory
Kris Kennaway
kris at FreeBSD.org
Mon Jun 9 10:10:04 UTC 2008
The following reply was made to PR misc/124410; it has been noted by GNATS.
From: Kris Kennaway <kris at FreeBSD.org>
To: Rene Schickbauer <rene.schickbauer at magnapowertrain.com>
Cc: freebsd-gnats-submit at FreeBSD.org
Subject: Re: misc/124410: malloc exposes previously free'd memory
Date: Mon, 09 Jun 2008 12:08:44 +0200
Rene Schickbauer wrote:
>> Description:
> malloc() exposes memory content from previous malloc/memory operations/free cycles.
>
> This can pose a security risk under certain circumstances. For example, a program generates a key, and forgets to memset() before it frees the memory. The memory contents (and the key) *may* be exposed on subsequent library calls or through unsafe network operations. E.g. this may expose security related data within a running process even after the process has "disposed" all of that data.
Only if the application is badly coded. The memory managed by malloc()
is only shared within a single processes address space, so it never
"leaks" to other applications unless the application itself is broken.
It is such an application that is traditionally regarded as insecure,
not the OS.
> While the stand-alone risk may (or may not) be very low, this security leak may work in conjuction with other software bugs to create a deep security hole.
>
> This especially the case, as many software developers seem to think that a free() disposes of the data.
This is not a reasonable assumption, I think. AFAIK free() has never
done this in C.
Anyway if you want to protect against this situation, you can set
MALLOC_OPTIONS=J. There is, of course, a substantial performance overhead.
Kris
More information about the freebsd-bugs
mailing list