Hacker News new | past | comments | ask | show | jobs | submit login
OpenSSL Security Advisory (openssl.org)
359 points by runesoerensen on Mar 19, 2015 | hide | past | web | favorite | 104 comments

By my count 12 out of the 14 vulnerabilities in this advisory are due to manual memory management. And past ones were similar.

This is security critical code, being developed and polished for more than a decade, and the only thing protecting the privacy of millions (billions?) of people. If any public project should have gotten this right, it should be this. Yet it can't.

Is this time to admit we simply can't do manual memory management at this level and move to something else? I know the performance boost is tempting, but I think we can't afford the consequences.

It's not been "polished" for more than a decade, it's been "patched" (for both bugs and features). Perhaps even "trashed".

OpenBSD uses a whole lot of C and doesn't tend to have these problems...

I'm not at all sympathetic to calls to ban some programming tool because it's "too hard". Just stop trying to squash harsh criticism as "toxic culture", this is how you imbue in people the importance of being careful with important code. Otherwise, even if they acknowledge that they should be careful, they'll write sloppy code, and it might even become popular, and you might have to support it...

I'd say the problem is in the documentation (or lack thereof.) I've had to use OpenSSL before and the question of "should this thing be freed after I use it?" was very common and only resolved fully by inspecting the source carefully. The heavy use of macros adds to the frustration; often, 3 or more layers of them hide the actual code that gets executed, making it hard to tell where things go.

On the other hand, I've also worked on some codebases that were very well-documented with respect to this: every function that either returned a pointer or accepted pointers made it clear if/when they should be freed (and if so, with what function.) One example of that looks like:

    void /* OWN */ *some_func(void *a, void /* OWN */ *b, void */* OWN */*c);
And the "/* OWN */" are intended to be read like "const" and "static", so this says the function returns a pointer to an object whose ownership is transferred to the caller, its first parameter does not change owners, the second one does, and the third is a pointer to an array of pointers whose ownership is passed to the function. The accompanying comment then says what function should be used to free the returned pointer, and what function will be used (by other code) to eventually free b and c.

I know that proposing Rust in this case almost became a cliché but Rust's borrowing mechanism introduces such a semantic and ensures correctness in compile time. Moreover, with RAII it can also zero the memory after object is out of scope.

Except when escape out to unsafe (as a lot of rust code does) or stop using rust because the borrow checker is brain dead:

https://github.com/rust-lang/rust/issues/6268 https://github.com/rust-lang/rust/issues/6393

Those bugs are 2 years old. And heaven forbid you have &mut self in a object.

Well, only for Box<> pointers, but yes

Ownership is for all structures on the stack. Box is little more than a rust-level wrapper around a raw pointer (well technically around a core::ptr::Unique which is the actual wrapper around a raw pointer)

Which part are you referring to with "only"? There's nothing particularly special about Box, at least, not in relation to the things the parent mentioned.

Whoops, misread "zero" as "deallocate". I meant that Box<> pointers are heap-allocated but deallocated when they go out of scope.

Why not define proper keywords for this?

    #define own
Then you don't need ugly comments...

    void own *some_func(void *a, void own *b, void * own *c);

> "Is this time to admit we simply can't do manual memory management at this level and move to something else? I know the performance boost is tempting, but I think we can't afford the consequences."

People have built a clean-slate TLS stack in OCaml and you can read about it on the MirageOS site [1]. There's also a Bitcoin Piñata built using this stack [2].

I'm told the performance is actually pretty good (though there's always room for improvement).

[1] http://openmirage.org/blog/introducing-ocaml-tls

[2] http://amirchaudhry.com/bitcoin-pinata/ and https://news.ycombinator.com/item?id=9027743

OpenSSL is just bad code. You can keep a reference around to memory in every garbage collected code.

What OpenSSL needs to do is to throw away all the extra code that makes it run on a billion obsolete platforms, remove support for things that aren't needed (renegociating encryption algorithms? Really if a client supported it before it can support them now), wrap the internal parts of the library and port it to C++ so that they can use smart pointers, then ban malloc.

Manual memory management isn't dangerous, malloc and low level primitives are (e.g you should never manually append strings, other than in your string library, which should automatically resize the strings as needed).

> Manual memory management isn't dangerous, malloc and low level primitives are

That is somewhat self-contradictory. Those "low level primitives" are manual memory management, so even by your own admission it is dangerous. Even Wikipedia calls smart pointers "automatic memory management."

There is a distinction to be drawn between a) malloc/free, b) RAII as with Rust or modern C++ and c) garbage collection.

We can have a debate about whether RAII is "manual memory management" or not, but it's clearly safer than malloc/free without the inefficiency of garbage collection.

>> What OpenSSL needs to do is ... port it to C++

Awful idea. The absolute last thing we want is for memory management to be out of OpenSSL's explicit control (then we would have two audit trails to worry about). Automatic memory management is manual memory management you've outsourced to somebody else.

(By this same argument, you also shouldn't turn on compiler optimizations when you build openssl.)

It's mainly due to OpenSSL doing exceptionally poor manual memory management. Lot's of the LibreSSL changes have involved removing that.

Flash Player, Adobe Reader, JVM, etc etc etc. I don't think it's a localized problem. And we only have so many people with the skills of the LibreSSL team to go around.

OpenSSL has not even a testsuite or build tool helpers to help finding those simple bugs, usually found with normal build and test methods, such a valgrind or AddressSanitizer. Insanity prevails.

Part of the problem was that they were (are?) using their own memory allocator, which was not only had been the source of many security vulnerabilities, but also broke Valgrind!

That was one of the first things the LibreSSL team ripped out.

So you're suggesting that the solution to manual memory managment bugs in the JVM is to use a memory managed language?

The memory management will have to be done manually at some point.

But many of these null pointer dereferences would _also_ be a DoS in a memory-safe, exception-free language like Rust. If you think x isn't null then try to access x.y... something's gonna blow up. If it was in Rust and someone used an unwrap() but there was no value, panic would DoS the system in much the same way, right?

(Same for Java, or C#, or what have you, though each connection would probably be in a try/catch so no real harm done, most likely.)

> If it was in Rust and someone used an unwrap() but there was no value, panic would DoS the system in much the same way, right?

A big difference is that the developer would have made the explicit choice at that point to dereference a pointer know to possibly be null. There's no implicit null (and having to wonder "by hand" for each pointer whether or not it could be null, with the risk that changes in any previous operation make make non-nullable pointers nullable without warning).

> Same for Java, or C#, or what have you

Java and C# also use implicit pervasive nullability, and at least deref'ing a null pointer there is a defined behavior.

OpenSSL is how not to do an important project. It is not indicative of C, opensource, underfunding, or any of the other common reasons normally given.

It is the result of too many cooks in the kitchen. Some of who in fact are not cooks.

I find it more apropos to suggest that they're all cooks, but meth cooks.

GC is not an answer to everything; sometimes works, sometimes you need to shortcut it.

Many people work on manual memory management for a reason http://event.scaladays.org/scaladays-sanfran-2015#!#schedule...

Security is a practice, not a programming language. Anthem uses C# and they are hacked almost every year. https://www.anthemfacts.com/

Who said GC? We're just talking about memory-safety...

Yeah, but they probably aren't getting hacked by someone sending a too-long username. If they were writing in an unsafe language, they'd almost certainly have those issues _in addition_ to everything else.

It's not the language, it's the programmers (and the lack of proper/regular code review).

You'll also notice that exactly none of the problems fixed in this advisory have any tests, either to check for regressions or for similar problems elsewhere. This is just negligent.

I would agree. (I already do, but) I wish more people who understood the importance of testing what you build would contribute to projects like this!

that's why we use LibreSSL

Of the 14 CVE reports, only 7 applied to LibreSSL. None of the "High" severity applied:


By severity, 4 of 9 of the "Moderate", and 1 of 3 "Low" were already fixed in LibreSSL, by my quick count.

Is there an update anywhere about how close libressl is to "prime time"?

LibreSSL is ready for prime time. It is the default SSL library on OpenBSD since version 5.6 [1], which was released on November, 1st 2014. Since then, more cleanup went in, and they developed libtls which is a new TLS API.

The latter is also included in several OpenBSD projects (OpenSMTPD, relayd, httpd).

The goal of libtls is to provide a sane API to develop new applications needing TLS. The problem with OpenSSL's API is that it exposes too much, and it's extremely easy to shoot yourself in the foot.

If you want to know more regarding LibreSSL, I recommend reading these:

http://www.openbsd.org/papers/bsdcan14-libressl/ http://www.openbsd.org/papers/eurobsdcon2014-libressl.html

Despite what the URL suggests, these are not papers but presentations at BSD related conferences. You might be able to find recordings of them on YouTube.

[1] http://www.openbsd.org/56.html

So, I am pretty proficient in these things, but I don't consider myself competent to declare it ready by code audit. I like the Google support, and I like the OpenBSD adoption. But since I am not running OpenBSD, I'd really like to see it make it into my distro's upstream by some community process. Endless ink and bits have gone into talking about 'cruft' in code that provokes big refactorings, when the what was considered cruft ends up being quite meaningful to correct and/or stability. To summarize - I'm with the gp post, I'm not convinced it's ready for primetime, either: it's stepping into giant shoes and has a very short track record.

Actually, libressl is practical drop-in replacement of openssl if you use only sane parts of openssl's functionality.

Biggest problem now is some upstream softwares still depends on insanity Openbsd devs nuked away, like RAND_egd() or won't admit that libressl actually exist :)

(https://devsonacid.wordpress.com/2014/07/12/how-compatible-i..., https://blog.hboeck.de/archives/851-LibreSSL-on-Gentoo.html)

But situation is changing as more and more upstream developers abandon those APIs : https://github.com/gentoo/libressl/blob/master/README.md

And I guess this is cool thing about libressl: even if it fails to replace openssl for real good, it is still forcing others to advance toward right direction (remember the linux fork fuss last year? You can disagree with me but I myself consider it linux's 'fault' not to have consistent mechanism of extracting entropy....it doesn't have to be arc4random but it could have been better in the first place if this IMO)

I don't know why they didn't keep RAND_egd() in, but just implement it as:

  int RAND_egd(const char *path)
      return -1;

Yeah, that's the quickest fix for some softwares but OpenBSD devs can be really 'uncompromising' when they consider some features broken/dangerous. That's how they managed to have "2 remote holes in default install" for decades I guess :/



That's not really an answer, though, is it? Because the feature is just as gone, it's just that it still remains API-compatible.

Here's the link to debian's wnpp bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=754513

Thanks for that; looks promising (even if these things take time /-). Does anyone know how viable it would be to create a shim for the new libtls-api for gnutls/nss? A shim for openssl isn't really all that interesting; hopefully that thing will die a horrible, slow death... and with some luck libressl can be the thing to nudge a better api into wider use.

Hm... this was posted on hn a while back, but didn't receive any comments. An implantation of part of the libtls (client) api by piping to the tls implementation in go's standard lib. If it really is this abstract, it should be possible to do this for both GnuTLS and NSS?:


Well, OpenBSD is one thing, but LibreSSL is about more than being OpenBSD's SSL implementation, right? If I'm running ubuntu or debian, at what point can I just say "fuck it, uninstalling openssl and switching to libressl as a drop-in replacement" without having to run through hours of hacky shimming or whatever and/or making various compromises at every turn?

Like other OpenBSD projects, it is developped against the OpenBSD tree and the 'portability goo' is added later on. It is the same case with libressl. There is GitHub repository: https://github.com/libressl-portable/ and release tarballs: http://ftp.openbsd.org/pub/OpenBSD/LibreSSL/

Keep in mind that LibreSSL is not a rewrite but a fork. Assuming your software uses the sane parts of the OpenSSL API, there shouldn't be any problems. If they use some interface that was deemed unsafe, well then I'd say it's time to fix the software (if the source is available). As far as ubuntu/debian are concerned, I'd say it's only a matter of time before it is available in the main repositories.

Well, it's in OpenBSD, so now?

And an important note from http://undeadly.org/cgi?action=article&sid=20150319145126

> The OpenSSL project provided information and patches to the LibreSSL project in advance of the announcements.

So 4 out of 14 needed fixing in -current, while the rest were either already fixed or not relevant to libressl. It would be interesting to know who fixed the ones that were fixed already, and when.

I guess that most of these were "fixed" by simply throwing away lots of garbage code from OpenSSL during the evolution of LibreSSL.

Don't undersell that man, priority zero in security is reducing the threat surface.

There are no quotation marks about it; it still counts.

You may be interested in the experience report of Ted Unangst about fixing security issues in OpenBSD:


We pushed an update on CloudFlare. This wasn't anywhere near as bad as some of the previous vulnerabilities.


Debian patches: https://lists.debian.org/debian-security-announce/2015/msg00...

Don't forget to manually restart affected services, check with "checkrestart -v" from the "debian-goodies" package if necessary.

Quick question I have subscribed to the RSS and receive emails thanks to IFTTT but why don't Amazon send also those emails ? Do they only send an email if you have to take some actions ?

Edit: You can find the recipe I'm using here: https://ifttt.com/recipes/270862-amazon-security-bulletins-t...

Anyone able to find an announcement from Rackspace? (I'm also an AWS customer so thank you for posting the above, which I'm certain would've been a considerable challenge for me to find!)

In the past they've posted advisories in their "Security & Vulnerabilities" forum[1], but I don't see one for this particular issue yet.

[1]: https://community.rackspace.com/general/f/53

There's a small note on https://status.rackspace.com/ right now:

> Open SSL Security Advisory

> Rackspace is aware and tracking the security advisory released by the Open SSL Community. We're closely monitoring the situation and evaluating any relevant actions.

> For more information regarding the specific details around the vulnerability please visit https://www.openssl.org/news/secadv_20150319.txt

> Posted on March 19, 2015 at 10:38 AM

Thanks (both) - status.rackspace.com is where I was hoping/expecting an update to be. Looks like I don't need to start calling my clients just yet!

So, this exploit allows for a Denial of Service Attack. While this does mean a single person could bring down your site, it does not appear that it will allow someone to gain access to your server via this exploit.

That's just the first of two high severity, right? The other sounds like Freakattack, but upgraded in severity. Perhaps others could correct me.

But the second high severity vulnerability was already known and fixed in most systems. E.g. Debian:


If this isn't patched on somebodies machine yet, they're doing something wrong ;). (Has Apple patched this yet?)

When Freak Attack came out, all I ever saw was about how to manually disable the export ciphers. So they finally come out with a fix to disallow them in the program?

It is exactly that

Also, this is only an issue if you are running version 1.0.2. It doesn't affect any other version.

Other CVEs in the bulletin affect other versions.

Between openssl-1.0.1k/l and openssl-1.0.1m, a major automated code reformatting was applied. Over 700,000 lines of code appear to have changed. (with whitespace ignored)

They've supplied tags to identify the start and the end of the code reformatting, but it's completely unclear if anyone has verified that they do not result in built binary changes.


That's quite heavy-handed. Funny that the reformatting actually broke the build for some configurations, even going unnoticed for a while(!!!). I'm glad I'm not a downstream maintainer having to deal with all that! :O

In fact.. If even a failing build weren't immediately discovered, what are the chances there haven't been introduced other bugs (that wouldn't fail to compile)?

If it's possible to do deterministic builds of OpenSSL, it should be pretty easy to verify that, no?

Minimum bounty of $2500 [0]. Those not lucky enough to be a citizen of Germany or other first-world country would be more lured by the dollar amount. As a US citizen, I'd be more interested in putting the fact that I got paid to fix a bug on a CV.

[0] https://hackerone.com/openssl

I think money incentives are so good. Gives those blackhats a reason to help.

I found the matching git commits for each vulnerability: http://www.solitr.com/blog/2015/03/openssl-vulnerability-bre...

How do they know that those segfaults aren't exploitable for arbitrary code execution?

Most of the DoS vulnerabilities appear to be null pointer dereferences, those are not exploitable simply because the attacker has no control over the pointer, it's always just null and it always crashes 'cleanly'. The same goes for the DoS-by-assert, those just kill the program, no direct chance for exploitation there.

The memory corruptions and use-after-frees are a bit more worrying, but they look pretty hard to trigger in real life.

Of course you should still upgrade asap, if that's the reason you're asking.

Writes through a null (or low valued) pointer can actually be easily exploitable on some embedded systems.


They're easily exploitable if (a) they're writes, (b) they're arbitrary, (c) they're targeting an architecture with an IVT mapped at 0x0, and (d) they're in code that can actually write the IVT (ie, an RTOS, or kernel code).

That's a pretty rare set of circumstances.

NULL pointer writes are also exploitable in the general case if they're offset, but none of these appear to be.

Also in many other circumstsances on general purpouse operating systems like Windows, Linux, OS X. There are a zillion examples just a web search away. Many well publicized and documented high profile RCE NULL vulns in browsers, Flash, kernels etc.

I'm waiting for an open SSL library implementation in Rust.

A language that statically checks for impossibility of null-pointer references (let alone out-of-bounds access) seems very apt for a critical and intensely-attacked library like this.

Six vulnerabilities in the X509/ASN.1 code! Inconceivable!

They're mostly DoSes, which rank a bit less as a vulnerability. If I know a world leader is going to a city and call in a bomb threat, yeah I disrupted things but it's a rather qualitatively different attack.

These don't seem to be directly in the ASN.1 code, but the consumer of such code, right? (Apart from the boolean compare?) That's probably just the result of having complicated structures to deal with, and no type system to tell you when you've made a bad assumption. And even with a good type system, you can still opt-in to explicitly failing. Code like "let x = foo.Value.bar // foo must have a value at this point" isn't totally uncommon. You can statically analyze and know which points will fail at runtime, but without exceptions, if any logic error counts as a vulnerability (because it kills the process), then we're basically saying the bar is perfect code, right?

With exceptions you'd just wrap the whole thing up and catch any such logic errors and save the process and destruct the socket. It seems like that'd have been a mitigation here (assuming structures aren't reused and sockets are exception safe).

No, the vulnerabilities are in the ASN.1 code, in places like libssl/src/crypto/asn1/a_set.c, tasn_dec.c. There's also stuff in the PKCS 7 and X.509 code, but that code is still very much ASN.1 code, since it contains handwritten coders and decoders for PKCS 7 and X.509 (the asn1 directory contains the code for the generic types, like INT, SET, STRING, etc.). There's also some weird stuff, like an X509 time comparison functions in x509_vfy.c that is like the ones in asn1/a_XXXtime.c.


Not really if you've ever had to work with ASN.1... (shudder)

Now now, there's an LL(1) parser for ASN.1, and it's easily found in the following reference:

Fouquart (P.), Dubuisson (O.) and Duwez (F.). - Une analyse syntaxique d'ASN.1:1994. - Internal Report RP/LAA/EIA/83, France Télécom R&D, March 1996. Only in French

In the first place, LL(1) parser for BER/DER is mostly trivial exercise, although somewhat tedious.

Problem with ASN.1 is not with the specification itself but mostly in the fact that many people want to parse BER/DER with code that directly populates some application-specific data structure and depends on ASN.1 syntax of what they expect to parse. With that you invariably get very complex interface between parser library and application where both components have to handle various special cases correctly (to the point that the whole thing is not even leaky abstraction, because it almost isn't abstraction at all).

Any tips for us hobbyist VPS owners running Debian 7? Latest version on a brand new digitalocean instantance is 1.0.1e! No sign of f,g,h,i or today's k.

As 0x0 says they are in 1.0.1e-2+deb7u15 which was just released a few minutes ago.

If you would like to know all the security update for debian you can subscribe to the mailing list: debian-security-announce@lists.debian.org See https://www.debian.org/security/

Be warned however that they send mail every few days and you have to read them to know which update is needed on your system.

On the other hand you can use Debian automatic upgrade system: unattended-upgrade. Which will update your system for security update. It does so every night so you won't have security update asap but if you update within the day it's generally okay


I can also recommend to enable automatic updates. It won't hurt, and if it does, it will be far less than a hacked server can cause in amount of damage.

Distributions generally backport security fixes, so a plain comparison of upstream version numbers won't generally work. You need to understand your distribution's versioning scheme and check package changelogs.

However, distributions generally release updates to their stable releases. Just install them. Installing security updates automatically is even better (better to have the occasional rare regression than a compromise and have to re-deploy the whole server).

IIRC Digital Ocean instances get updates by default from Digital Ocean mirrors that are not always up to date with the source. You may want to switch to the official sources.

The default debian droplet configuration is to use Digital Ocean's mirror for the main archive where delay doesn't really matter, and security.debian.org for security updates. That is exactly how you want to be configured.

These patches are included in 1.0.1e-2+deb7u15

AFAIK you should look into the "built on:" line. If the date is: Tue Mar 17 21:30:08 UTC 2015, then the the package is already updated.

Here's RedHat's roundup article on which of their supported products are impacted by which CVE:


Yay for being on the trailing edge...

How bad will this actually be?

As techscruggs put it [0], the ClientHello sigalgs DoS vulnerability does not seem to facilitate unauthorized access. It may allow malicious parties to take you down, but not get in your system.

The other big one is the RSA silently downgrades to EXPORT_RSA thingy. This is the now famous SMACK TLS [1], disclosed 2 weeks ago by researchers from INRIA, IMDEA, and MicroSoft. Most of the software is getting patched (OpenSSL already has) but still very scary.

[0] https://news.ycombinator.com/item?id=9231958

[1] https://www.smacktls.com

nit picking: SMACK TLS is a collection of attack on TLS found by the inria and microsoft, FREAK is the attack mentionned in the CVE

Thank you, but I cannot edit anymore.

Readers of my above comment, please note that it should read:

"This is [part of] the now famous SMACK TLS"

Is this site down for anyone else? Would be ironic if they didn't patch their own servers and got DDossed

We've posted an update on the DigiCert blog: https://blog.digicert.com/openssl-patches-security-vulnerabi...

No affect on any issued SSL Certificates, that's always a positive.

> This issue was reported to OpenSSL on 22nd October 2014 by Karthikeyan Bhargavan of the PROSECCO team at INRIA. The fix was developed by Stephen Henson of the OpenSSL core team. It was previously announced in the OpenSSL security advisory on 8th January 2015.

which means they ignored CVE-2015-0204 for 6 months

3 months. The fix was implemented in January. Its severity was simply upgraded.

Registration is open for Startup School 2019. Classes start July 22nd.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact