From owner-freebsd-bugs@FreeBSD.ORG Mon Jun 9 10:10: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 788A51065679 for ; Mon, 9 Jun 2008 10:10: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 616858FC0C for ; Mon, 9 Jun 2008 10:10:04 +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 m59AA4Fq062444 for ; Mon, 9 Jun 2008 10:10:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m59AA4mW062443; Mon, 9 Jun 2008 10:10:04 GMT (envelope-from gnats) Date: Mon, 9 Jun 2008 10:10:04 GMT Message-Id: <200806091010.m59AA4mW062443@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org From: Kris Kennaway 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: Kris Kennaway List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2008 10:10:04 -0000 The following reply was made to PR misc/124410; it has been noted by GNATS. From: Kris Kennaway To: Rene Schickbauer 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