[Cryptography] defending against common errors (was: secure erasure)

[John Denker]

On 09/11/2016 10:28 AM, Ray Dillinger wrote:

> What the hell was Heartbleed, if not an attack
> on memory that ought to've been secure-erased?

Well, since you asked ... heartbleed was /primarily/ an attack
on broken code, i.e. code that referenced out-of-bounds data.

At some secondary or tertiary level, zeroizing the buffer offers
a degree of error concealment.  It is does not correct the error
or even detect the error;  it only conceals it.

> [...] are attacks we're dealing with in the field
> right now, and we need ways to defend against them!

Agreed.  I hate bugs.  We need ways to defend against common
errors and common attacks.

HOWEVER that is several jumps removed from assuming that
"secure erasure" is the only means or even the best means
of defense.

Serious suggestion:  Let's not ask the compiler guys to do
something they don't want to do, such as turning off the
optimizations that make it hard to zeroize out-of-bounds
data.  Instead let's start by asking them to do something
that fits within their world-view *and* is more useful
anyway, namely bounds-checking.

For critical code including security-related code of the
kind I am familiar with, there should be verrry little
runtime penalty for bounds checking, because the code should
be manifestly correct at compile time.  The runtime checks
can be optimized out.

Furthermore, for code that I write, if the compiler cannot
prove at compile time that all the references are in bounds,
I would be happy to have that treated as a compile-time error.
Even if the code was technically correct before, I would be
happy to rewrite it to make it /manifestly/ correct.

I know some smart, security-conscious guys who write in C and
won't consider any other language, not even C++, because they
wouldn't feel "in control".  They worry that the language is
copying stuff behind their back, making it harder to zeroize
everything.  With all respect to those guys, zeroization is
not the primary goal.  Security is the primary goal.  If you
use a language that protects you against out-of-bounds access,
the most common mistakes go away, and zeroization becomes
much less of a priority.

Here's yet another reason why focusing on "secure erasure"
is not the whole story, or even the main part of the story.
You zeroize the buffer after you are "through" with it.
Alas that does not defend against broken code that leaks
information from the buffer /before/ you are through with
it.

Key concept:  I hate bugs.

There is such a thing as fault tolerance.  If you do it right,
it's a life-saver ... but if you do it wrong, it is worse than
nothing.  Let me explain:

Suppose we have a system with N layers of fault tolerance.
Now suppose there are N-1 faults, which are fully concealed.
That's a problem, because as soon as the next fault occurs,
boom, you're dead, with no warning.

The better approach is to make sure that the first N-1
errors throw lurid warnings.  The mission can continue,
but the fault tolerance must be married to fault detection.
If the fault detection is not baked in from the beginning,
the system is both unsafe and undebuggable.

  I can provide a wide variety of real-world examples if
  anybody is interested.

Let's be clear:  I am not saying that zeroization is ipso
facto a bad thing.  Sometimes it is necessary, and sometimes
it is helpful as part of a belt /and/ suspenders /and/
crazy-glue approach.  If you want to use memset_s() /and/
munmap() /and/ bounds-checking that's fine with me.  OTOH
I am saying that zeroization by itself is not sufficient.
Overemphasis on zeroization is a bad thing, especially if
it leads to non-detection of broken code.


-------------- 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/20160912/3b44a06a/attachment.sig>