
OpenSSL Security Advisory - runesoerensen
http://openssl.org/news/secadv_20150319.txt
======
BoppreH
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.

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

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

~~~
doomrobo
Well, only for Box<> pointers, but yes

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

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

------
Nusyne
Relevant fixes have been commited to OpenBSD

[https://marc.info/?l=openbsd-
cvs&m=142677386615089&w=2](https://marc.info/?l=openbsd-
cvs&m=142677386615089&w=2)

[https://marc.info/?l=openbsd-
cvs&m=142677382215078&w=2](https://marc.info/?l=openbsd-
cvs&m=142677382215078&w=2)

[https://marc.info/?l=openbsd-
cvs&m=142677372515025&w=2](https://marc.info/?l=openbsd-
cvs&m=142677372515025&w=2)

[https://marc.info/?l=openbsd-
cvs&m=142677368815015&w=2](https://marc.info/?l=openbsd-
cvs&m=142677368815015&w=2)

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

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

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

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

[https://blog.cloudflare.com/openssl-security-advisory-
of-19-...](https://blog.cloudflare.com/openssl-security-advisory-
of-19-march-2015/)

------
0x0
Debian patches: [https://lists.debian.org/debian-security-
announce/2015/msg00...](https://lists.debian.org/debian-security-
announce/2015/msg00082.html)

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

------
ca98am79
AWS statement about it: [http://aws.amazon.com/security/security-
bulletins/openssl-se...](http://aws.amazon.com/security/security-
bulletins/openssl-security-advisory---march-2015/)

~~~
bshimmin
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!)

~~~
briancurtin
There's a small note on
[https://status.rackspace.com/](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](https://www.openssl.org/news/secadv_20150319.txt)

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

~~~
bshimmin
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!

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

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

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

[https://www.debian.org/security/2015/dsa-3125](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?)

~~~
orblivion
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?

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

[https://www.openssl.org/blog/blog/2015/02/11/code-
reformat-f...](https://www.openssl.org/blog/blog/2015/02/11/code-reformat-
finished/)

~~~
0x0
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)?

------
Sevzinn
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](https://hackerone.com/openssl)

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

------
joliss
I found the matching git commits for each vulnerability:
[http://www.solitr.com/blog/2015/03/openssl-vulnerability-
bre...](http://www.solitr.com/blog/2015/03/openssl-vulnerability-breakdown/)

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

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

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

[https://cansecwest.com/csw07/Vector-Rewrite-
Attack.pdf](https://cansecwest.com/csw07/Vector-Rewrite-Attack.pdf)

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

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

------
jgrahamc
LibreSSL sync: [https://github.com/libressl-
portable/openbsd/commit/7cd43a39...](https://github.com/libressl-
portable/openbsd/commit/7cd43a391fc4972fb5c79acbcf70d430ded5228a)

------
tripl
Mirror
[http://pastebin.com/raw.php?i=ycxrFtXf](http://pastebin.com/raw.php?i=ycxrFtXf)

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

~~~
moe
_Inconceivable!_

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

~~~
alricb
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_

~~~
dfox
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).

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

~~~
staz
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/](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

~~~
eloy
[https://filippo.io/psa-enable-automatic-updates-
please/](https://filippo.io/psa-enable-automatic-updates-please/)

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.

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

[https://access.redhat.com/articles/1384453](https://access.redhat.com/articles/1384453)

Yay for being on the trailing edge...

------
archimedespi
How bad will this actually be?

~~~
nmc
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](https://news.ycombinator.com/item?id=9231958)

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

~~~
baby
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

~~~
nmc
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 _"_

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

------
flavmartins
We've posted an update on the DigiCert blog:
[https://blog.digicert.com/openssl-patches-security-
vulnerabi...](https://blog.digicert.com/openssl-patches-security-
vulnerabilities-2/)

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

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

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

