misc/124410: malloc exposes previously free'd memory

[rene.schickbauer at magnapowertrain.com]

The following reply was made to PR misc/124410; it has been noted by GNATS.

From: rene.schickbauer at magnapowertrain.com
To: freebsd-gnats-submit at FreeBSD.org
Cc: kris at 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