[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87bl402xn8.fsf@keithp.com>
Date: Thu, 07 Oct 2021 17:00:43 -0700
From: Keith Packard <keithp@...thp.com>
To: David Holland <dholland-libc@...bsd.org>, libc-coord@...ts.openwall.com
Subject: Re: freezero() and freezeroall()
David Holland <dholland-libc@...bsd.org> writes:
> Is that a realistic threat model?
I think so? Imagine a large persistently running network-connected
application. Type in a secret, it gets left around in application
visible memory "forever". Download code from the network days later and
if that code can compromise overall app security, it can scan all of
memory looking for interesting information, without needing to
compromise the rest of the system.
A version of this function which guaranteed that the information was
lost to the application would be sufficient to avoid disclosure in this
case.
> So, like I said, I don't really see the point...
Yeah, I'm pretty much on the same side here, just trying to make sure we
understand the whole environment. Erasing from memory should mean
erasing from memory, not just removing from application visible
memory. The simplest way of doing that is to just explicit_bzero before
the call to free().
Hrm. If this page has ever been written to swap, it sure would be nice
to be able to erase that copy as well, otherwise there's a persisted
version of the data which survives power off.
--
-keith
Download attachment "signature.asc" of type "application/pgp-signature" (833 bytes)
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
