[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YV9kQYHsAWKnJ+yM@netbsd.org>
Date: Thu, 7 Oct 2021 21:18:57 +0000
From: David Holland <dholland-libc@...bsd.org>
To: libc-coord@...ts.openwall.com
Subject: Re: freezero() and freezeroall()
On Thu, Oct 07, 2021 at 12:36:42PM -0700, Keith Packard wrote:
> David Holland <dholland-libc@...bsd.org> writes:
>
> > I'm not sure I see the point of this function -- if you're calling
> > explicit_bzero because you're handling secrets, skipping the bzero
> > because the page is about to be unmapped seems like a mistake, so
> > explicit_bzero followed by free seems just as good as anything and
> > easier to reason about than adding something new.
>
> Yeah, that's probably best practice for most cases as it also avoids
> access to data from paths that don't use the current application page
> table, and doesn't depend on the OS doing anything special.
>
> However, if your threat model only covers access to the currently mapped
> pages in the application, then skipping the bzero when the pages are
> getting unmapped would be sufficient, and might offer significant
> performance benefits.
Is that a realistic threat model? It can help interfere with
complicated attacks that rely on carefully constructed sequences of
allocs and frees, but that's not about secrets. If I have a secret,
leaving it sitting on the free page queue in the kernel risks exposure
via kernel bugs. It's not _that_ hard to imagine the kernel reusing
the page for kernel data, failing to initialize fully, then leaking
part of the results to userland, since such leaks are fairly common
and hard to detect and stamp out. Or someone also having a
read-kernel-memory exploit on hand.
I wouldn't rely on it.
> > If you're not handling secrets, then it seems like security theater.
>
> I can imagine an operating system which promises to clear anonymous
> pages when unmapped, possibly using some OS-visible memory clearing
> hardware. In that case, doing the explicit_bzero before unmapping the
> pages would be unnecessary extra work.
> [...]
True, but unless the kernel's formally verified (one day!) I wouldn't
rely on it.
In any event, for mitigating free-twice issues and the like it seems
to me that the right thing to do is have ordinary free() zero (or
deadbeef) everything based on some compile or link-time setting, not
add new not-really-portable opt-in interfaces that most critical code
won't have heard of and would need to be patched to use.
So, like I said, I don't really see the point...
--
David A. Holland
dholland@...bsd.org
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.
