Use after free bug in OpenSSL

http://ftp.openbsd.org/pub/OpenBSD/patches/5.4/common/008_openssl.patch

by beala • 12 years ago

153 89 12 years ago

ftp.openbsd.org

andrewchoi• 12 years ago

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

saranagati• 12 years ago

appears to be a different bug. nothing as big as heartbleed though from what I can tell.

yarbelk• 12 years ago

Not a silly question. Not all of us know which bug report is which sensationalised bug name. I know I don't. Admittedly, some bugs deserve to be sensationalised.

Dylan168072• 12 years ago

You didn't look at the fifteen second description of what Heartbleed is?

IgorPartola2• 12 years ago

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.

Danieru• 12 years ago

You're right about the custom malloc in so far as but bug would have been caught earlier without it.

yaur2• 12 years ago

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.

Dylan168072• 12 years ago

It's a bug that got in the way of memory hardening that could have stopped heartbleed, but it's not actually related.

Heartbleed is reading too far, this is not that.

rtpg• 12 years ago

I think this is more of a bug that could enable something like Heartbleed. So squashing this might make other bugs less interesting to exploit.

eudox• 12 years ago

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

lawnchair_larry• 12 years ago

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

jewel• 12 years ago

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...

cybernoodles• 12 years ago

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

regecks• 12 years ago

There are bug bounties for OpenSSL.

1. https://hackerone.com/openssl

2. https://www.google.com/about/appsecurity/patch-rewards/

midas0077• 12 years ago

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.

leoc• 12 years ago

The prize money could stand to be a whole lot larger however.

userbinator3• 12 years ago

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.

midas0077• 12 years ago

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.

cynicalkane3• 12 years ago

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.

x0x0• 12 years ago

and, ideally, a rigorous test suite; for something that is essentially implementing nested state machines, that probably involves an adversarial state machine aware tester (ie get to state 1; attempt to break; get to state 2, attempt to break, etc), a fuzzer, and a serious unit test suite

I get that part of this is a community problem, etc, but a lack of the above on a security product is amazing

yelnatz• 12 years ago

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

Another!

jevinskie• 12 years ago

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...

caf• 12 years ago

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

xorgar8312• 12 years ago

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• 12 years ago

Static analysis isn't going to beat humans, also: https://hackerone.com/

xorgar8312• 12 years ago

Cool, thx!

projuce• 12 years ago

You should also check out https://bugcrowd.com

dbbolton3• 12 years ago

What is up with that patch command? Why not

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

?

jzwinck• 12 years ago

You should use && instead of ; but otherwise I wondered the same thing. Useless use of cat, it seems.

dbbolton3• 12 years ago

Why? How likely is `cd /usr/src` to fail?

sarnowski• 12 years ago

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.

dbbolton3• 12 years ago

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

frik• 12 years ago

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...

gcb0• 12 years ago

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

barkingcat• 12 years ago

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...

"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.

legulere• 12 years ago

It seems to be even more overly complex and hard to use (when not using the compatibility layer) than openssl though. The ease of use for programmers is also very important as an error of the application programmer can be as bad as an error in the ssl library.

victormx2• 12 years ago

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

justincormack• 12 years ago

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

victormx2• 12 years ago

thanks this is what I was talking

danieltillett2• 12 years ago

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.

clarry3• 12 years ago

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.

danieltillett2• 12 years ago

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

nemo3• 12 years ago

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.

peteretep• 12 years ago

Yes, yes a million times. Wonder if this will prompt them to. For a rewrite to have any traction, it would need implementing by a team with some credibility, and they're probably one of the few teams with that credibility

dllthomas5• 12 years ago

Would it really have to be a fork? Working with the original team could be to everyone's benefit.

clarry3• 12 years ago

Some anecdotes from recent discussion suggest it's not so easy to work with the original team. Also, if their standard for quality is what it is, it might be hard for another project to start changing things.

nemo3• 12 years ago

Given the scale of reworking and reorganizing that would be involved, I assumed a fork would be the only viable approach.

peterbotond• 12 years ago

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/

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

clarry3• 12 years ago

More like as of 15 years ago.

Use after free bug in OpenSSL

Related Stories