[Cryptography] Secure erasure

[Ray Dillinger]

On 09/10/2016 02:10 PM, Patrick Pelletier wrote:

> I would argue the opposite: the most likely threat comes from a
> Heartbleed-style vulnerability, where your own process gets tricked into
> revealing the contents of its own memory.  In that sort of a threat
> model, the hardware doesn't matter, swap doesn't matter, caches don't
> matter.  All that matters is what's visible in the process's address
> space.  This is the sort of threat that the original question in this
> thread can defend against, by zeroing memory.

Yes.  That is in fact the point.

Heartbleed is EXACTLY the kind of vulnerability I'm worried
about.  The OS allocated memory to the server for new buffers
out of memory the process had already allocated and released.
Because it was going to the same process, the OS "optimized"
and didn't bother to clear it before reallocating.  The source
code for the server program contained instructions to clear
it before releasing. But the machine code didn't. The compiler
had "optimized" and skipped those instructions on the grounds
that it was a write to dead data that was about to be released.

Then somebody comes along and tells the server they want to
see more buffer memory than the process had written since the
buffer was (re)allocated, and they get data that the programmers
thought had been erased, from buffers the programmers had
released, sitting there in the "unused" space of live buffers
allocated after that release.

My point is that the programmers weren't just idiots.  They
made a legitimate effort to be secure.  They may have even tested
and made sure the memory clear *DIDN'T* get optimized away at
the time the code was written, but they had no way to explicitly
specify destroying that data. And some later version of the
compiler, or some different compiler than they used, or some
different combination of environment, settings, or OS found a
way to rip them off.

Score:
   optimizers, two.
   Programmers, zero.
   System security, minus several million.

				Bear

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20160910/298bdd3a/attachment.sig>