<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Apr 17, 2014 at 6:51 PM, Jerry Leichter <span dir="ltr"><<a href="mailto:leichter@lrw.com" target="_blank">leichter@lrw.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="">On Apr 17, 2014, at 5:01 PM, Peter Trei <<a href="mailto:petertrei@gmail.com">petertrei@gmail.com</a>> wrote:<br>

We're all talking about a serious bug in OpenSSL code.<br>
><br>
> But the bug itself isn't a crypto bug. It's a general programming bug, which<br>
> could occur in any server code when the client can say 'send me the first X<br>
> bytes of buffer FOO', and the server does that without checking that<br>
> X <= length(FOO).<br>
><br>
> Its a bounds checking bug, which just happened to appear in security related<br>
> code.<br>
><br>
> The same error could occur in many other parts of a server program, with the<br>
> same devastating consequences.<br></div></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="">
</div>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.<br>
<br>
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.<br></blockquote><div><br></div><div>I think you may have missed my point. This style of security hole could exist in server programs which don't use OpenSSL; indeed, which don't use crypto at all. All it requires is that the client/server protocol allows the client to cause a unchecked read as I described, and sensitive data be available in program-accessible memory, whether put<br>
</div><div>there by the server, or dredged up unzeroed in a malloc.<br></div><div><br></div><div>Fixing crypto code, and/or walling it off as you suggest, won't prevent Heartbleed<br>style bugs in other server code. <br>
<br></div><div>We've known for years that buffer overflows can be used for code injection. In Heartbleed, we're seeing the same problem being used for data exfiltration.<br><br></div><div>Fixes which prevent read/write access to code segment memory, or execution <br>
of data as code, won't solve this. Perhaps Intel MPX will, once we move to <br>processors  which have it, compilers support that feature, and server software <br>is rebuilt.<br></div><div><br></div><div>Peter Trei<br>
</div></div></div></div>