Date: Mon, 9 Jun 2008 11:30:03 GMT From: rene.schickbauer@magnapowertrain.com To: freebsd-bugs@FreeBSD.org Subject: Re: misc/124410: malloc exposes previously free'd memory Message-ID: <200806091130.m59BU3wC075974@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: rene.schickbauer@magnapowertrain.com To: freebsd-gnats-submit@FreeBSD.org Cc: kris@FreeBSD.org Subject: Re: misc/124410: malloc exposes previously free'd memory Date: Mon, 9 Jun 2008 12:48:00 +0200 > Rene Schickbauer wrote: > > >> Description: > > malloc() exposes memory content from previous malloc/memory > operations/free cycles. ... > It is such an application that is traditionally regarded as insecure, > not the OS. Yes, i know. But given that such bugs in applications are often not exposed for a long time (see the Debian OpenSSL fiasco), additional security might not be a bad idea. > > 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. Given that i have to work with newbies quite a lot, i'd say it is, i'm afraid. > AFAIK free() has never done this in C. I'm very well aware of that. Nevertheless, free'd memory content may live on in RAM for a long time. As i wrote, it may be possible to access the data even after the process free`d it. Maybe even by pulling the RAM and putting it in another computer. An example, how this could happen: User puts Laptop into standby; Kernel notifies the process that it's going to standby, process closes files and dumps the access password by freeing the relevant piece of memory. When the computer wakes up again, the process asks the user for the access password to re-open the files. Now, the software developer assumes that: 1) No one can access the password while computer is in sleep mode, because he removed it from the processes memory 2) The encrypted file is secure, because the user MUST input the password again, because it is not known to the system Sadly these are assumptions if seen in many programs. > Anyway if you want to protect against this situation, you can set > MALLOC_OPTIONS=J. There is, of course, a substantial performance overhead. Where security is concerned, performance is not that much of an issue. Thanks for the tipp, i seem to have overlooked "J"... LLAP & LG Rene
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200806091130.m59BU3wC075974>