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.
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.
> "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).
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.
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.)
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.
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.
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.
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.
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:
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.
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 :)
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)
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 :/
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?
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.
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.
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 ?
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!)
> 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.
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.
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?
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)?
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.
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.
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.
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.
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.
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.
> 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
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.