[Cryptography] Something that's bothering me about the heartbleed discussion.....

[Jerry Leichter]

On Apr 17, 2014, at 5:01 PM, Peter Trei <petertrei at gmail.com> wrote:
We're all talking about a serious bug in OpenSSL code.
> 
> But the bug itself isn't a crypto bug. It's a general programming bug, which
> could occur in any server code when the client can say 'send me the first X
> bytes of buffer FOO', and the server does that without checking that 
> X <= length(FOO). 
> 
> Its a bounds checking bug, which just happened to appear in security related
> code. 
> 
> The same error could occur in many other parts of a server program, with the
> same devastating consequences. 
It's worse than that.  It could occur in any program that *uses* OpenSSL.  Among such programs, there are many that allow for plugins and other open-ended extensions.  Those are just as hazardous.

So it's not just OpenSSL.  It's every bit of code that *uses* OpenSSL, and every bit of code the *uses* the code that *uses* OpenSSL.

> Fixing OpenSSL is important. But we need to look at ways of 
> preventing this kind of bound check error generally. Discussing fixes that
> specifically make crypto code more reliable won't catch issues outside of
> crypto code.
Indeed.

I can suggest a fix, but it's a hard one:  Crypto code *must never run in the same protection domain as untrusted code*.

If you assume a safe compiler for a safe language, you can assume that *it* maintains separated protection domains for different components.  I'm not sure there's any language/compiler I'd fully trust, but you can come close enough that you might reasonably take the risks involved.

If you assume existing languages like C and C++, the only way to maintain separate protection domains is via the operating system:  Put the crypto code in its own process, with a carefully minimized and controlled connection to the operational code which has no direct access to any of the crypto capabilities.

Note that both the VPN model and the "use ssh tunneling" model do this, though they provide no way for the application code to influence *anything* about the crypto - even such things as the identification to use when choosing keys.
 
                                                        -- Jerry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4813 bytes
Desc: not available
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20140417/16082721/attachment.bin>