
Use after free bug in OpenSSL - beala
http://ftp.openbsd.org/pub/OpenBSD/patches/5.4/common/008_openssl.patch
======
userbinator
It's good to see that one of the positive effects of Heartbleed is that it
motivated people to inspect OpenSSL's code, leading to more bugs being found
and fixed.

This is supposed to be how open-source works; it's unfortunate that it had to
take a huge vulnerability to cause this motivation.

~~~
midas007
It still doesn't get at two top points of meta: TLS is a horribly
overfeatured, design-by-committee standard AND C makes it incredibly easy to
screw up and so requires zealous attention to a defensive coding style to
introduce fewer flaws.

~~~
cynicalkane
It's possible to defensively code in C, particularly with modern tooling (some
of which lets you write provably secure code) and good process.

The fact of the matter is the OpenSSL people simply did not care about writing
good code, and the open source community as a whole was happy to assign their
most critical security features to a library widely known to be confusing and
terrible and not even remotely properly analyzed or tested.

Like most people, I see Heartbleed as a process failure; unlike most people, I
think the process failure goes far beyond TLS or OpenSSL or C.

~~~
ahomescu1
> The fact of the matter is the OpenSSL people simply did not care about
> writing good code, and the open source community as a whole was happy to
> assign their most critical security features to a library widely known to be
> confusing and terrible and not even remotely properly analyzed or tested.

Sure, but open source developers have no obligation whatsoever to anyone.
Considering they're not being paid in any way for their code, they can write
whatever code they want and under whatever process they like. The problem IMHO
is that OpenSSL was used for highly sensitive commercial uses (like Gmail,
Amazon and others); I think responsibility should fall on companies who used
the library without checking it first (Disclaimer: I'm not in anyway
associated with OpenSSL or any crypto library, this is just how I see things).

~~~
midas007
Dead wrong. When lives and money are on the line, there is obligation
somewhere along the line back to the source. Maybe it stops elsewhere, maybe
it doesn't. If folks are depending on open source for life-safety or risk the
safety of innocent or targeted individuals, there is an obligation at some
point to ensure systems are as secure as humanly possible. More importantly,
regardless of circumstances, there is a fundamental duty of engineering
ethics. [0] They're not just cliche words or some worthless university course,
but the implications of how design decisions and construction of something
affects the real world. That crappy commit to [project here] might be the
difference between someone living and someone dying.

[0]
[https://en.wikipedia.org/wiki/Engineering_ethics](https://en.wikipedia.org/wiki/Engineering_ethics)

~~~
ahomescu1
The page you linked to starts with: _Engineering ethics is the field of
applied ethics and system of moral principles that apply to the practice of
engineering. The field examines and sets the obligations by engineers to
society, to their clients, and to the profession._ I read this to only apply
to professional engineering, where engineers do work for money or other forms
of payment. I don't think freely-given (or almost freely, such as GPL code)
hobbyist code should be held to these standards, for one reason: it's being
given for free, with no expectations in return. If the developer expects
nothing from you in exchange for the code, you shouldn't expect anything more
than getting the code as-is.

~~~
vfclists
I disagree with this.

If the hobbyist knows that the code may be used in a critical environment then
the hobbyist should withdraw the code or make it very clear its suitability
for some task has not been tested. It is rather like asking someone for
directions and the person misleads you on the basis that you are not paying
him for directions.

Ethics always apply whether you are being paid or not.

~~~
ahomescu1
> If the hobbyist knows that the code may be used in a critical environment
> then the hobbyist should withdraw the code or make it very clear its
> suitability for some task has not been tested.

It's already made very clear in the license that the code hasn't been tested,
and comes with no guarantees. How much clearer than that can it be?

Also, you can't really withdraw code from the Internet. Even if you take down
the original repository, there may be dozens of forks.

~~~
sitkack
That is CYA boilerplate, OpenSSL is most surely designed and implemented for
security even if the license says it is for making cupcakes.

------
jevinskie
I believe this is the same patch as previously written about here on April
10th: [http://www.tedunangst.com/flak/post/analysis-of-openssl-
free...](http://www.tedunangst.com/flak/post/analysis-of-openssl-freelist-
reuse)

~~~
caf
The patch is slightly different, but it is the same bug.

------
frik
One may consider Mozilla's NSS library (Netscape invented SSL, "Network
Security Services") as an alternative to OpenSSL. It has an compatible API
layer (extra package), is used by Firefox, (Chrome), OpenOffice and has more
sane default settings. Check out the comparison tables:
[http://en.wikipedia.org/wiki/Comparison_of_TLS_Implementatio...](http://en.wikipedia.org/wiki/Comparison_of_TLS_Implementations)

~~~
gcb0
Chrome used NSS on android only because of license or something else... now it
uses openssl all around.

~~~
barkingcat
Chrome is planning to move to openssl for everything, doesn't mean it uses
openssl "now all around".

According to the planning doc linked earlier this week, it might take some
time to get openssl into chrome. The Plan is for it to occur over 4
"milestones". I'm not sure how long each milestone will take, but suffice it
to say, it's not "now".

And it was the other way around. Only Chromium Android used OpenSSL.
Everywhere else it used NSS (linux, mac desktop, windows)

Quote from
[https://docs.google.com/document/d/1ML11ZyyMpnAr6clIAwWrXD53...](https://docs.google.com/document/d/1ML11ZyyMpnAr6clIAwWrXD53pQgNR-
DppMYwt9XvE6s/edit?pli=1)

"Currently, Chromium supports two different SSL/cryptographic backends. On
Windows, OS X, iOS, Linux, and Chromium OS, Chromium uses NSS. On Android,
Chromium uses OpenSSL. "

Please check your sources carefully and don't write unfactual information.
Especially in the realm of crypto it's important to get the details right.

It would be even better if you edited your post so future readers don't have
to read my post at all in order to get the correct information.

------
nemo
I wish Theo and his colleagues would create a fork of OpenSSL that was up to
OpenBSD/OpenSSH standards. It would be a huge level of work, but I'd happily
donate to help fund it.

~~~
peterbotond
src/lib/libssl is in the openbsd tree as of 2 days ago approximately, and
being trimmed as seen in commits: [http://www.openbsd.org/cgi-
bin/cvsweb/src/lib/libssl/](http://www.openbsd.org/cgi-
bin/cvsweb/src/lib/libssl/)

edit: precesion: libssl has seen a set of large commits, in the past 48 hours,
and other libcrypto related changes.

~~~
clarry
More like as of 15 years ago.

------
andrewchoi
Sorry if this is a silly question, but is this simply the Heartbleed bug? Or
is this a different memory leak bug?

~~~
IgorPartola
This is not the Heartbleed bug. I am not certain this is actually an
immediately exploitable vulnerability (aka a sexy bug). What this looks like
is an instance where the code calls free() on a buffer, then assumes the
buffer is still available (uses it in some way). The patch seems to make it
only free the buffer after it is empty, preventing this behavior. I think this
is related to OpenSSL's issue with malloc and the way it handles memory
allocation.

~~~
yaur
No this was written about a couple days ago. It frees the memory and because
Open uses a LIFO memory allocater it can "safely" assume that whatever was
still in there is still in there. I belive that in order to exploit this you
would need to exhaust its internal allocator (so that it requests more from
the OS) and your payoff would be... having your connection dropped.

This was discovered in the course of someone's attempt to figure out why
OpenSSL randomly drops connections when its using a sane/OS supplied
allocator.

------
xorgar831
It seems like someone should start a Sourceforge for security project; a place
that tracks and does high quality static analysis of open source projects, and
makes the reports readily available.

~~~
robbyt
Static analysis isn't going to beat humans, also:
[https://hackerone.com/](https://hackerone.com/)

~~~
projuce
You should also check out [https://bugcrowd.com](https://bugcrowd.com)

------
yelnatz
That's pretty sick. I'd rather have bugs fixed now than later.

Another!

------
victormx
Anyone known a real alternative to SSL to secure communications? No GPG,
POW(or bitcoin, similar, etc.)

~~~
justincormack
You need to be more specific about what kind of communications. You could look
at spiped as one example
[https://www.tarsnap.com/spiped.html](https://www.tarsnap.com/spiped.html)

~~~
victormx
thanks this is what I was talking

------
danieltillett
I think that this is a good sign. I know everyone has been saying that OpenSSL
code is terrible (can't say I have looked myself), but if this is the worst
bug found since heartbleed then maybe it is better than it appears.

~~~
clarry
This isn't a bug found in a thorough audit of the entire OpenSSL code base.
This is a bug that was discovered while trying to understand why applications
using OpenSSL would run into trouble after disabling the code that made it
impossible to detect Heartbleed with OpenBSD's malloc safety features.

~~~
danieltillett
I understand this, just with the amount of attention OpenSSL has been getting
not much worse seems to have come out.

------
cybernoodles
It appears Heartbleed has riled up the Hound dogs. It's unfortunate the funds
aren't available for bug bounties in OpenSSL.

~~~
regecks
There are bug bounties for OpenSSL.

1\. [https://hackerone.com/openssl](https://hackerone.com/openssl)

2\. [https://www.google.com/about/appsecurity/patch-
rewards/](https://www.google.com/about/appsecurity/patch-rewards/)

~~~
midas007
Beware of the chilling effects of collecting Google bounties, they will claim
a reward is invalid if you've blogged about the vuln outside of their
timetable.

~~~
innoying
Isn't that common sense? If you disclose the bug publicly before it's patched
you won't get the reward...

~~~
midas007
Sort of. But Google has a history of how it treats independent researchers.

------
eudox
Are we going to post every new OpenSSL bug until everyone switches to miTLS?

~~~
lawnchair_larry
There are no plans to switch to miTLS. It's a toy project unsuitable for
displacing OpenSSL.

~~~
jewel
I believe that most other implementations are unsuitable for displacing
OpenSSL for licensing reasons alone. I didn't look at every other
implementation since I was looking for one that supported a specific mode, but
the majority of them are GPL with the option to license for proprietary code.
GnuTLS is LGPL, at least.

Wikipedia has a pretty good list of possible implementations:

[http://en.wikipedia.org/wiki/Comparison_of_TLS_Implementatio...](http://en.wikipedia.org/wiki/Comparison_of_TLS_Implementations#Overview)

------
dbbolton
What is up with that patch command? Why not

    
    
        cd /usr/src; patch -p0 </path/008_openssl.patch
    
    ?

~~~
sarnowski
Because now your command isn't /path/ independant. The original assumed you
downloaded the patch to your current directory and you can just copy&paste
this command. Your example requires me to modify your line making this
"process" more error prone.

~~~
dbbolton
In that case, their command is exactly as "error prone" to anyone who did not
download the patch to the PWD.

