

OpenSSL Security Advisory - tlo
https://www.openssl.org/news/secadv_20150108.txt

======
tptacek
The optics of this advisory are bad, of course, but these are probably not
operationally important bugs for most people:

* DTLS segmentation fault in dtls1_get_record ( _only impacts people who use DTLS, and is a null pointer deref, which usually isn 't exploitable_)

* DTLS memory leak in dtls1_buffer_record ( _same, and only exhausts memory_ )

* no-ssl3 configuration sets method to NULL ( _a non-standard build produces a null pointer crash in SSL3 negotiation_ )

* ECDHE silently downgrades to ECDH ( _this looks like a server can in an oddball situation lie about forward secrecy --- also, this only impacts OpenSSL clients, like curl_ )

* RSA silently downgrades to EXPORT_RSA ( _a server can sabotage the security of a session, which it can do in a variety of other ways anyways --- also, this only impacts OpenSSL clients, like curl_ )

* DH client certificates accepted without verification ( _breaks client authentication, which not many people rely on, but only affects servers that (a) do TLS client auth and (b) trust DH-key-issuing CAs, which are "extremely rare and hardly ever encountered"_)

* Certificate fingerprints can be modified ( _this one I actually wonder about the sev:lo on; it 's low because it doesn't impact browsers, but certificate blacklists are common in enterprise software_)

* Bignum squaring may produce incorrect results ( _this is just weird_ )

~~~
tlb
That bignum one is weird. The patch suggests the character of it: something in
the carry logic between 32-bit words, replicated for each assembly
architecture as well as C. Here's the C version:

    
    
       #define mul_add_c2(a,b,c0,c1,c2) {	\
       	BN_ULONG ta=(a),tb=(b),t0;	\
       	BN_UMULT_LOHI(t0,t1,ta,tb);	\
      -	t2 = t1+t1; c2 += (t2<t1)?1:0;	\
      -	t1 = t0+t0; t2 += (t1<t0)?1:0;	\
      -	c0 += t1; t2 += (c0<t1)?1:0;	\
      +	c0 += t0; t2 = t1+((c0<t0)?1:0);\
       	c1 += t2; c2 += (c1<t2)?1:0;	\
      +	c0 += t0; t1 += (c0<t0)?1:0;	\
      +	c1 += t1; c2 += (c1<t1)?1:0;	\
       	}
    

The test case adds this number:
0x80000000000000008000000000000001FFFFFFFFFFFFFFFE0000000000000000

If you were wondering whether OpenSSL code has really gotten too complicated,
wonder no more.

Full patch:
[https://github.com/openssl/openssl/commit/e078642ddea29bbb6b...](https://github.com/openssl/openssl/commit/e078642ddea29bbb6ba29788a6a513796387fbbb#diff-6dd63052b7680975a9eeb33dca68da52L478)

~~~
rab_oof
It's clear LibreSSL is only a half measure.

TLS is far too complicated with design-by-committee, special vendor extension
sauce nonsense. Heck, the FIPS code was rushed and basically done at the
behest of US/Canadian govts. OpenSSL should consider burning their deadwood
and stop adding features until it gets its house in order.

There's no telling how large of an attack surface remains at the protocol
level, in the codebase and with CAs being compelled to issue rogue certs for
MITMs.

Moreover: Can TLS features be narrowed to focus on popular and high-value use-
cases instead of SCTP, UDP, oh look a bird feature? It's fine for hacking on,
but not production code. (If "TLS" is evolutionarily to "Perl," who's working
on a "Python"?)

BTW: What ever happened to the cert WoT overlay 'moxie0 was working on?

~~~
nanolith
It is true that TLS is part of the problem. But, it is also a widely deployed
standard that cannot be changed overnight. That's why LibreSSL is necessary.

We need to build simpler protocols that make better use of cryptographic
primitives, but first, we have to push back the tide. Eventually, TLS will be
superseded by a better standard. But, this is something that even if started
today with the most aggressive schedule would take 5 to 10 years to go
industry-wide.

------
Tobu
Seems like INRIA is starting to do some formal checking of OpenSSL. Here's
their page:
[http://prosecco.gforge.inria.fr/](http://prosecco.gforge.inria.fr/)

Here's another OpenSSL flaw that was found with Coq, a formal prover:
[http://ccsinjection.lepidum.co.jp/blog/2014-06-05/CCS-
Inject...](http://ccsinjection.lepidum.co.jp/blog/2014-06-05/CCS-Injection-
en/index.html)

------
nanolith
While this particular vulnerability in OpenSSL isn't nearly as bad as some of
the other recent ones, it drives me crazy that we still have NULL pointer
dereferences in something this critical. The worst part of this library is
that the way it is organized makes it difficult to find these problems, or to
use tools such as static analyzers to help. There are some amazing static
analysis tools out there for C, but they are rendered useless by some of the
hackery used in this library, such as their custom allocators. I don't mean to
sound negative -- the OpenSSL team has done a great job making this library
available in the first place -- but given how heavily this library is relied
upon, better discipline is needed in this code base.

LibreSSL is a step in the right direction, and I commend the OpenBSD team for
taking on this alternative. However, it's only a starting point. The entire
approach of OpenSSL is dated, and it has not done a good job keeping up with
our modern understanding of solid security engineering. The code base needs to
be overhauled from the ground up with modern security and software development
practices in mind. If ever there were a library that should be designed using
formal proofs in software, it's this one. Even basic TDD with good code
coverage would catch the majority of the bugs that have been discovered in
OpenSSL over the past ten years.

</rant>

~~~
MichaelGG
Rust would also eliminate these bugs, as a class. And Rust has inline asm, for
those cases where you need platform specific. Finally, Rust van export a C ABI
library, so you could make a drop-in replacement.

~~~
nullc
"these bugs, as a class"

It absolutely would not eliminate CVE-2014-3570 or many other of the
cryptographic bugs that show up in OpenSSL and other TLS implementations.

This kind of axiomatic thinking that memory safety equals all safety almost
resulted in Rust being less safe (IMO) than C in these other respects: the
normal types in rust are all defined to overflow even though overflow is
almost always a bug, and so you couldn't use static analysis on arbitrary rust
codebases to warn you about these issues (where you can in C because signed
overflow is undefined, so an analysis tool can always flag that as an error
without it being a false positive). Fortunately, it sounds like Rust is moving
to fix this ( [http://discuss.rust-lang.org/t/a-tale-of-twos-
complement/106...](http://discuss.rust-lang.org/t/a-tale-of-twos-
complement/1062) ), which is a big improvement.

But it's important to not be fuzzy about the risks. There is a well
established link between safety equipment and risky behavior in driving and
bicycling;
([http://en.wikipedia.org/wiki/Risk_compensation](http://en.wikipedia.org/wiki/Risk_compensation)).
I don't mean to suggest that better isn't better and we shouldn't use safer
tools, but if our response to safer tools is to lower our vigilance, even the
slightest, we may get worse results.

~~~
nanolith
I agree with this assessment. There is nothing inherently wrong with C. While
alternative languages have certain advantages, there are clear reasons why
core foundational libraries like OpenSSL are written in C: portability, age of
the code base, knowledge of the contributors, etc.

While I would personally like to see a pragmatic move towards C++ in many of
these low level libraries for some of the additional type safety and mechanics
the language provides, this is a normative idea only, and I am under no
delusion that it would necessarily result in better code. Good software
transcends language.

I would, however, like to see enhancements to the style of code being written
in this library so that tools like static analyzers and contract verifiers can
provide meaningful results. A craftsman is only as good as how well he/she can
make use of the available tools. Much of OpenSSL defies analysis, which is why
the more bone-headed of these vulnerabilities, such as Heartbleed, are so hard
to find.

It's impossible to eliminate all bugs. But, it is possible to build code in
such a way that when there is the suspicion of a bug, one has a fairly good
idea of how and why it is occurring. It is also possible to structure code --
even C and assembler -- so that it's easier to read and analyze, be this by
eye or using tools. Finally, it's possible to structure code so that automated
unit testing provides meaningful results regarding boundary conditions and
contracts between functions. This latter point isn't meant to find bugs on its
own, but rather to codify the more subtle bits of contracts between functions
and data structures in a defensive way to ensure that future patches -- like
the one that caused Heartbleed -- don't stomp on assumptions made in software.

~~~
MichaelGG
> There is nothing inherently wrong with C

The fact that almost no teams on Earth seem to be able to ship large codebases
without severe vulnerabilities rather disputes that idea.

~~~
nanolith
Let me assure you that this is true regardless of language or platform.

I've done vulnerability analysis on codebases written in C++, Java, C#,
Objective C, Ruby, and Python. I've found bugs in each of these platforms. The
biggest differentiator I found was experience. More experienced software
developers, on average, made fewer bugs resulting in vulnerabilities than less
experienced software developers.

There is no magic language or platform that makes writing secure software
easy. There are tools, techniques, and training that can help. But, these can
only help. Writing quality software -- of which security is an important part
-- is a difficult process that requires a lot of experience and discipline.

~~~
MichaelGG
Please point to the CVEs for the plethora of remote code execution bugs in
apps written in Java and C#, for instance.

I went through every single security bulletin MS published over the past
couple years. The vast majority of the serious ones were 100% due to memory
safety issues. The biggest exception was due to trying to sandbox arbitrary
code (their .NET equivalent to Java applets).

If you have some counter-evidence, showing C to be even remotely as safe as,
say, Java, please step forward. If you are actually saying "Well I found a lot
of SQL injection bugs in code written in Java", that's a different issue. And
I'm sure you're aware of it.

There's probably a name for the use of rhetoric of the form "Nothing's
perfect. Therefore X and Y are just as good, since they are both imperfect."

~~~
nanolith
Luckily, I don't have to respond by your goalposts.

You are hammering on a single class of security vulnerability out of hundreds
of potential vulnerabilities. How does Rust prevent a confused deputy
vulnerability? How about SQL Injection? Okay... well, what about all of the
potential side channel attacks?

People in higher level languages tend to believe that the relative safety of
their position means that they have to be less vigilant about vulnerabilities.
That is often what I have found. The number of vulnerabilities overall were
similar, but the type of vulnerabilities were different. Because there was a
completely mistaken belief that these platforms were "more secure", security
practices were often sloppy. Most of these vulnerabilities were at the
application level. So, looking for Microsoft CVEs isn't going to help you.

The C++ code bases tended to have more senior level people working on them,
who were more careful about both defects and vulnerabilities. Code bases in
higher level languages, in general, had more junior level people working on
them. Largely, the number of vulnerabilities were similar.

Again, I'm speaking of my own experience. But, I think that many researchers
in the field would give you a similar story. I'm always wary of people
promising silver bullets over hard work.

~~~
MichaelGG
So by your own logic, if experienced C++ developers wrote in, say, Rust, they
would not make mistakes like SQL injection, _and_ they wouldn't be making all
the memory-safety mistakes, either.

Edit: If your overall point is that systems are laughably insecure, and most
app devs just leave gigantic holes open, sure, great. But let's not compound
that by making their OSes and low-level network stuff run arbitrary code for
anyone on the Internet.

~~~
nanolith
It's not nearly that simple. Look, I get it: you're a fan of Rust. That's
great. Use whatever language floats your boat.

But, it takes more than language features to solve security issues. Memory
vulnerabilities are only a small piece of the wide range of potential defects
that exist in software. These are also defects that largely go away with
training and experience.

I can teach most C / C++ developers how to manage memory and pointers in a way
that avoids all of the pitfalls that Rust is designed to prevent. It is
absolutely possible to write reasonably secure software in most general
purpose programming languages. This is true for C, C++, and even Rust. Don't
believe me? Spend some time studying the formal proof behind the se
implementation of L4, written in C.

All of this being said, I am a big fan of high-level languages. For my
personal work, I write 80% of my software in Literate Haskell and around 20%
in a lower level language like C++. But, I also understand the limitations
that comes with abstraction, and they are big. System level code operates
under a lot of constraints, and the abstraction that come with "safe"
languages can come at the cost of this code working at all.

A good software engineer uses whichever tool he / she needs to build good
software. If the process is followed, then there is no reason why we can't
have an ecosystem that uses whichever languages are best for the problem. For
most system level stuff, C/C++ are perfectly fine. If you want to use Rust,
great. But, don't delude yourself into believing that your language choice
trumps good engineering practice. It never will. Don't believe me? Write some
software that can work around the Halting Problem in Rust, and get back to me.
Because, that's the sort of intelligence you would need in a compiler or a
tool to replace good practice.

~~~
MichaelGG
If you can teach people how to write safe C code, you should setup a site and
rake it in. Meanwhile, Mozilla, Microsoft, Google, and others have tried to
build safe applications and simply fail due to memory safety issues. When such
high profile teams cannot deliver, then at some point you gotta say "hmm,
maybe the language is at fault".

I understand you like C/C++ and want to point out that if people delivery on a
superhuman effort, then we can have nice things. Meanwhile, in reality, so
far, this just doesn't happen. Lemme know when we can go a year without a
memory safety issue getting tons of systems owned.

~~~
nanolith
When Rust has been around long enough, and people have started adopting it,
then we'll see vulnerability reports in systems developed in Rust too. As I
said, there are no silver bullets in security.

------
kazuho
Kind of off-topic, but I wonder when they will release OpenSSL 1.0.2.

1.0.2 includes important fixes (e.g. support for ALPN which is mandatory in
HTTP/2, adds support for cross-root certificate validation).

------
martinknafve
I'm unable to compile this on Win32 (I don't have any problems compiling older
versions). I don't understand how the code could compile for anyone, maybe
it's a platform specific issue. Take a look here on line 80:

[https://github.com/openssl/openssl/blob/master/crypto/cversi...](https://github.com/openssl/openssl/blob/master/crypto/cversion.c)

The variable cflags isn't defined. I suspect it should be CFLAGS. I can make
it compile locally by changing that, and it would make the code in the
function consistent with the other code in the same file.

I thought C defines were case sensitive on all platforms. Anyone knows better
than me?

~~~
Dunnorandom
You have to keep in mind that OpenSSL runs several Perl scripts as part of its
build process. And it's one of these scripts that generates a header which
defines the cflags variable:

[https://github.com/openssl/openssl/blob/103b171d8fc282ef435f...](https://github.com/openssl/openssl/blob/103b171d8fc282ef435f8de9afbf7782e312961f/util/mkbuildinf.pl)

Apparently this is done to work around potential length limitations in C
string literals.

~~~
martinknafve
I can compile the previous versions. I've used the same script for several
years, and its not until this version today I have an issue. When seeing the
issue, I actually tried compiling the old versions again and those still
worked.

It would seem odd if they actually change the build process in a security
patch, right? The instructions on how to build OpenSSL on Windows has not been
changed in 2 years.

~~~
tedunangst
> It would seem odd if they actually change the build process in a security
> patch, right?

No release of OpenSSL has ever been "the previous release plus the minimal
patches for a security fix". This isn't a security patch. It's a new release
that happens to include some security patches.

~~~
martinknafve
It's a security patch in the sense that the only way to get the security
patches is to install the new version.

But thanks for the info. That seems like a pretty bad practice when it comes
to a lib such as OpenSSL. Having to do changes to the build process to
integrate an urgent security fix seems less than optimal.

------
sarciszewski
[https://github.com/openssl/openssl/compare/OpenSSL_1_0_1j......](https://github.com/openssl/openssl/compare/OpenSSL_1_0_1j...OpenSSL_1_0_1k)

And for future releases, it may be worthwhile to watch this URL to find
unpatched vulnerabilities:

[https://github.com/openssl/openssl/compare/OpenSSL_1_0_1k......](https://github.com/openssl/openssl/compare/OpenSSL_1_0_1k...OpenSSL_1_0_1-stable)

;)

~~~
tedunangst
> VMS fixups for 1.0.1

Oh, whew!

~~~
yellowapple
Oh good; I was worried there for a second; now I know that my VAX will be nice
and secure!

------
ck2
Nothing on centos/epel yet.

------
chinathrow
[https://www.openssl.org/news/secadv_20150108.txt](https://www.openssl.org/news/secadv_20150108.txt)

~~~
tptacek
This should be the link this story points to.

~~~
dang
Changed from [http://marc.info/?l=openssl-
announce&m=142046772204265](http://marc.info/?l=openssl-
announce&m=142046772204265). Thanks.

------
KamiNuvini
Security advisory: [https://mta.openssl.org/pipermail/openssl-
announce/2015-Janu...](https://mta.openssl.org/pipermail/openssl-
announce/2015-January/000007.html)

~~~
acdha
Here's a link which doesn't double as a survey to see how many HN readers will
override the HTTPS validation warning:

[https://mta.opensslfoundation.net/pipermail/openssl-
announce...](https://mta.opensslfoundation.net/pipermail/openssl-
announce/2015-January/000007.html)

