OpenSSL Security Advisory
openssl.org
openssl.org
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.
The memory management will have to be done manually at some point.
That was one of the first things the LibreSSL team ripped out.
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).
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."
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.
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.)
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
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/
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...
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);
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.
#define own
void own *some_func(void *a, void own *b, void * own *c);It is the result of too many cooks in the kitchen. Some of who in fact are not cooks.
(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.)
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.
http://marc.info/?l=openbsd-tech&m=142677518515567&w=2
By severity, 4 of 9 of the "Moderate", and 1 of 3 "Low" were already fixed in LibreSSL, by my quick count.
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.
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)
int RAND_egd(const char *path)
{
return -1;
}http://marc.info/?l=openbsd-tech&m=140512043210089&w=2
https://www.mail-archive.com/linux-crypto%40vger.kernel.org/...
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.
> The OpenSSL project provided information and patches to the LibreSSL project in advance of the announcements.
https://blog.cloudflare.com/openssl-security-advisory-of-19-...
Don't forget to manually restart affected services, check with "checkrestart -v" from the "debian-goodies" package if necessary.
> 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
Edit: You can find the recipe I'm using here: https://ifttt.com/recipes/270862-amazon-security-bulletins-t...
https://www.debian.org/security/2015/dsa-3125
If this isn't patched on somebodies machine yet, they're doing something wrong ;). (Has Apple patched this yet?)
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.
https://www.openssl.org/blog/blog/2015/02/11/code-reformat-f...
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)?
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.
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.
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.
Not really if you've ever had to work with ASN.1... (shudder)
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
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).
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).
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.
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).
https://access.redhat.com/articles/1384453
Yay for being on the trailing edge...
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.
Readers of my above comment, please note that it should read:
"This is [part of] the now famous SMACK TLS"
No affect on any issued SSL Certificates, that's always a positive.
which means they ignored CVE-2015-0204 for 6 months