Date: Mon, 9 Jun 2008 10:10:04 GMT From: Kris Kennaway <kris@FreeBSD.org> To: freebsd-bugs@FreeBSD.org Subject: Re: misc/124410: malloc exposes previously free'd memory Message-ID: <200806091010.m59AA4mW062443@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR misc/124410; it has been noted by GNATS. From: Kris Kennaway <kris@FreeBSD.org> To: Rene Schickbauer <rene.schickbauer@magnapowertrain.com> Cc: freebsd-gnats-submit@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200806091010.m59AA4mW062443>