From owner-freebsd-bugs@FreeBSD.ORG Mon Jun 9 11:30:04 2008 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 05C73106567C for ; Mon, 9 Jun 2008 11:30:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id E11F88FC18 for ; Mon, 9 Jun 2008 11:30:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m59BU3aK075977 for ; Mon, 9 Jun 2008 11:30:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m59BU3wC075974; Mon, 9 Jun 2008 11:30:03 GMT (envelope-from gnats) Date: Mon, 9 Jun 2008 11:30:03 GMT Message-Id: <200806091130.m59BU3wC075974@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org From: rene.schickbauer@magnapowertrain.com Cc: Subject: Re: misc/124410: malloc exposes previously free'd memory X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rene.schickbauer@magnapowertrain.com List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2008 11:30:04 -0000 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