Date: Fri, 11 Apr 2014 01:48:00 -0400 From: ari edelkind <edelkind-list-freebsd-security@episec.com> To: freebsd-security@freebsd.org Subject: Re: A different proposal Message-ID: <CAPxErSWipLD2QKnd35v=NuxRw4Gs25O5vB3gL=P_PtfND9GYDw@mail.gmail.com> In-Reply-To: <C239A0B5-31C3-4842-97D5-3C048A909028@vpnc.org> References: <9eeba1ab-2ab0-4188-82aa-686c5573a5db@me.com> <8D81F198-36A7-47F4-B486-DA059910A6B4@spam.lifeforms.nl> <867g6y1kfe.fsf@nine.des.no> <CAA3htvv_DePi_A-UjtG0hvybfRSE8KgvSjq5m3yM0FGX9%2BL6QQ@mail.gmail.com> <C8D2649E-4BD0-4124-9915-CCE1DCCB1A6A@vpnc.org> <CAPxErSVKxXEgBCh0g77193Hz8vTZiUcVTXuMAQyx=Bm=BMcVNg@mail.gmail.com> <C239A0B5-31C3-4842-97D5-3C048A909028@vpnc.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Apr 10, 2014 at 6:28 PM, Paul Hoffman wrote: > I have heard from others, less interested in self-aggrandizement than > Theo, that OpenSSL's malloc was significantly to blame. > OpenSSL's simplistic malloc implementation exacerbated the information exposure in this case, so you might well say that it had a hand in the _severity_ of the bug. Depending on your system malloc, using that instead may or may not have yielded any improvement (and in OpenBSD's case, it would have) -- but the cause was an incredibly silly programming bug that had nothing to do with malloc. I'll get to just how silly it was shortly. I'm not saying OpenBSD's is better, > I'll say that: OpenBSD's is better. :) On that note, re-reading my prior mail, i didn't mean to come off as unflattering toward OpenBSD's malloc. They did a pretty good job with it. > Amateurish failure to check the sanity of user-supplied input was to > > blame. > > Yes. > > > Idiotic, error-prone protocol specifications, written by > > non-programmers, were to blame. > > Not in this case. > I'm not sure how you came to this conclusion, but let me explain how i came to mine: The heartbeat protocol structure sits within the SSL3 record. In the code, you know the length of the data at this point. But instead of using the length of this data to determine the size of your payload, the spec _also_ makes the user supply his own length. This practice is error-prone, and i've seen it cause problems before (the SSH2 spec is also full of garbage like this -- in fact, observing a similar protocol in the SSH2 spec is precisely what led me to discover a remote-execution vulnerability in the cryptlib ssh code, circa 2006). Now, the spec tries to make up for this bizarre requirement by telling the programmer to discard the packet if the specified payload length is "too large", but this is essentially passing the buck: if the spec says, "the implementer MUST avoid all memory-related bugs," and the programmer introduces a bug, does this mean the spec authors are absolved because the program is non-compliant? The best way to avoid memory-related bugs is to avoid practices that commonly result in them. The apparent silliness of this bug then comes to a head when you realize that the programmer who introduced the heartbeat bug is the same person who wrote most of the heartbeat RFC. Updates to ports are inherently slower than patches from the OpenSSL team. > My point is not that either ports or distribution are "too slow" for > everyone: it is that if you are sure you need something faster than them, > there is another option. > I didn't claim that the ports update was or will be fast enough for everyone. What i was getting at was that if you want the new version, but a new port hasn't yet been released, you can update the port files in your local ports tree yourself; it takes a rudimentary knowledge of how the port system works. You are, quite literally, installing the most recent version from source (as you suggest), except that you get automatic package management. ari
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAPxErSWipLD2QKnd35v=NuxRw4Gs25O5vB3gL=P_PtfND9GYDw>