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

[Guido Witmond]

On 04/18/14 00:51, Jerry Leichter wrote:
> 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). 
>
>> 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*.

I fully agree!

However, we need to go even further. Every parser (that reads data from
outside) needs to run in their own protection domain.

That's what microkernels allow us to do. However, in the past a certain
mr Torvalds chose the monolithic kernel because it was faster, and
backwards compatible with other unices.

Now we have virtualisation. Instead of one computer to manage, we need
to manage a lot more. Talking about going backwards.

However, the cloud has a silver lining. This time literally.

Check out the MirageOS [1] project. "Mirage is a unikernel for
constructing secure, high-performance network applications across a
variety of cloud computing and mobile platforms. Code can be developed
on a normal OS such as Linux or MacOS X, and then compiled into a
fully-standalone, specialised kernel that runs under the Xen hypervisor."

There is no operating system anymore! So no backwards compatibility at
that level.

The price is steep, one would have to rewrite every application, darn.

Regards, Guido.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 897 bytes
Desc: OpenPGP digital signature
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20140418/94f22ad3/attachment.pgp>