
OpenSSL Security Advisory - FiloSottile
https://www.openssl.org/news/secadv/20160503.txt
======
roddux
Memory Issues: Episode III - Revenge Of The Buffer Overflow (2016)

In all seriousness, repeated occurrences such as these should make people
consider other languages for new projects. Despite being quite a C fanboy, I
have to admit that even I think manual memory management should be a thing of
the past now.

~~~
Someone1234
I too love C.

I'd almost go so far as to say you need to do a security review before you
write one line of code. You need to evaluate if C is a requirement or a
preference, and if the security of the project can withstand being written in
C (e.g. edge code that may be attacked).

The argument that C (and C++) can be written well or flawlessly is tiresome.
"Perfect code" is a fallacy that has been proven over and over again to be
untrue and dangerously untrue. You should assume the code quality is less than
optimal as your starting point.

I am not promoting any specific alternative (Rust, Java, Go, etc) I am just
saying that C/C++ are insecure by design and should be avoided unless they're
a project requirement.

~~~
robert-wallis
This sounds like a witch hunt. Java has horrible security bugs even today.

Bugs can be found in code written in all languages.

~~~
tveita
Most the horrible security bugs in Java show up in the sandbox, where
attackers can supply arbitrary code for you to run.

In contrast, Java as a server language has an excellent security record IME.
The last public patch panic I can remember was in 2011 with the denial of
service bug regarding parsing of floating points. There has been other
security bugs regarding cryptography etc, I'm sure, but in general you can
feel very secure running Java on your servers.

It is a shame that security bugs for both are bundled together, making every
sandbox compromise a "Remote exploitable" vulnerability. The "applet" use case
should probably just die, there is no indication that Java sandboxing will
ever be secure, the design is unsound.

~~~
hansjorg
Oracle is deprecating the Java browser plugin in JDK 9, ie. the applet use
case. There will still be support for Java Web Start though.

~~~
ThisIs_MyName
I've always wondered why nobody sandboxes Java applets in a LXC/Docker
container or in a chrome sandbox the same way flash is contained.

------
jbaviat
One of the two issues was interestingly found using Clang fuzzing
capabilities. This is in-process fuzzing, that Clang libFuzzer makes quite
easy:

[http://blog.llvm.org/2015/04/fuzz-all-
clangs.html](http://blog.llvm.org/2015/04/fuzz-all-clangs.html)

[http://llvm.org/docs/LibFuzzer.html](http://llvm.org/docs/LibFuzzer.html)

~~~
ashitlerferad
Another fuzzer, quite amazing one actually (it managed to create PNG/JPEG
images from fuzzing).

[http://lcamtuf.coredump.cx/afl/](http://lcamtuf.coredump.cx/afl/)

~~~
jbaviat
The (truly amazing) lcamtuf blog post you are referring to is this one:

[http://lcamtuf.blogspot.fr/2014/11/pulling-jpegs-out-of-
thin...](http://lcamtuf.blogspot.fr/2014/11/pulling-jpegs-out-of-thin-
air.html)

------
FiloSottile
Patch:
[https://github.com/openssl/openssl/commit/70428eada9bc4cf314...](https://github.com/openssl/openssl/commit/70428eada9bc4cf31424d723d1f992baffeb0dfb)

Advisory mirror:
[https://gist.github.com/FiloSottile/99ad6b52688f5a1f0a5fa200...](https://gist.github.com/FiloSottile/99ad6b52688f5a1f0a5fa2009a891490)

Preliminary analysis:
[https://news.ycombinator.com/item?id=11621038](https://news.ycombinator.com/item?id=11621038)

~~~
CiPHPerCoder

        But it no longer
        checked that there was enough data to have both the MAC and padding
        bytes.
    

... I am beyond words.

~~~
pjmlp
Just the C usual stuff, but good bone coders use all the warnings and
analyzers from gcc and clang and never commit such errors.

~~~
adrianN
I'm not sure whether you are sarcastic or not, but to me the seemingly endless
amount of this kind of bug in high profile projects like OpenSSL is pretty
good proof that nobody can write secure C.

~~~
CiPHPerCoder
What about
[https://github.com/jedisct1/libsodium](https://github.com/jedisct1/libsodium)
then?

Very high profile, no CVEs found to date.

EDIT: Can't respond to lambda below.

I was responding to THIS assertion, not proposing libsodium as a general
purpose openssl replacement: "nobody can write secure C."

To which I said, here's a project that's written in C that's apparently
secure.

~~~
lambda
You can generally respond even if you don't have the link by clicking on the
timestamp ("1 hour ago" or whatever) to go directly to my comment.

My comment was not meant to point out that libsodium doesn't make a general
OpenSSL replacement. It was meant to point out that if you restrict the
problem domain enough, of course it's possible for people to write secure C. I
can write a secure "Hello, World!" program; even a secure networked "Hello,
World!". But being able to write a secure "Hello, World" does not mean that I
am capable of writing secure C in general.

Pointing out one small piece of code that is apparently secure isn't what a
claim like "nobody can write secure C" is really about. "Nobody can write
secure C" means that when programming in the large, implementing standardized
network protocols with all of their warts, having codebases that evolve over
time, that no one can consistently and reliably write secure C.

So sure, libsodium may, as of now, have no known CVEs. But it's based on NaCL,
which is written by djb. He's also written qmail and djbdns, both claimed to
be secure. qmail has had exploitable problems on 64 bit platforms with large
amounts of virtual memory:
[http://www.guninski.com/where_do_you_want_billg_to_go_today_...](http://www.guninski.com/where_do_you_want_billg_to_go_today_4.html)
and djbdns has had security problems exploitable on any platform:
[http://article.gmane.org/gmane.network.djbdns/13864](http://article.gmane.org/gmane.network.djbdns/13864).

OpenBSD is likewise a minimalist system with a heavy emphasis on security, but
even with that approach, they have had to change their slogan to "Only two
remote holes in the default install, in a heck of a long time."

Now, of course, this does point out a few things. Minimalism is important for
security; and more minimalist approaches and care in writing code can help
reduce the frequency and severity of critical vulnerabilities. But even given
some of the most careful, security conscious approaches, people still make
mistakes.

That's why, when practicing responsible security, you should use defense in
depth. In addition to all of the care, review, minimalism, principal of least
authority, isolation, etc, you should also use tools that can prevent whole
classes of bugs at compile time.

~~~
CiPHPerCoder
> You can generally respond even if you don't have the link by clicking on the
> timestamp ("1 hour ago" or whatever) to go directly to my comment.

[https://twitter.com/CiPHPerCoder/status/727530489255485440](https://twitter.com/CiPHPerCoder/status/727530489255485440)

~~~
lambda
Ah, that sucks.

------
nickpsecurity
ASN.1 is so well-understood at this point that Galois even has a high-
assurance toolkit for it:

[http://cps-vo.org/node/1577](http://cps-vo.org/node/1577)

Maybe someone should forward that to OpenSSL team and suggest they pay Galois
to crank out a bunch of encoders/decoders for them for anything requiring that
in OpenSSL. Or LANGSEC people behind HAMMER toolkit. Or even the Cap n Proto
guy.

Seriously, the number of preventable failures in this software, esp memory, is
a strong indicator of why you should never use it.

~~~
peterwwillis
> Maybe someone should forward that to OpenSSL team and suggest they pay
> Galois

Here's where you can donate your money to pay Galois:
[https://www.openssl.org/support/donations.html](https://www.openssl.org/support/donations.html)

Once they've received the funds i'm sure they'll get right on it.

~~~
nickpsecurity
Lol. I thought they've had money all this time and not spent it on stuff that
works. Meanwhile, LibreSSL did more in a few weeks for their code quality than
its owners did in a year. Why would I give them money expecting something
different?

The right course, if we're talking Galois, is for them to try to ask Galois to
donate some time or tooling to improve critical aspects of a widespread-
deployed library. They already make money with grants and stuff for code they
often open-source. They might even find thr deliverables useful for them. So
OpenSSL team can feel free to give them a call.

------
mcs
ASN.1 parsing in implementations of several different standards have had this
class of issue for well over a decade. ip phone and software stack
vulnerabilities in, for example in asterisk, specifically for ASN.1 handling
have probably been used by our intelligence community for a long time. The
safe implementations are probably ran in virtual machine languages.

~~~
cyphar
I think we should all agree to move from ASN.1 as quickly as possible. Many
implementations don't include some of the wacky features (like recursive
serialisation of structures), because nobody needs them and they cause bugs.
But there is so much more weirdness in ASN.1 that it would honestly be much
nicer if we used JSON (as an example of the other extreme). Maybe there's a
nice binary, typed format which doesn't resemble the 80s we should be using.

~~~
lmm
Thrift/Protobuf/etc. are reasonably nice IME.

~~~
cyphar
The cool thing about protobuf is that it allows automated parser generation
(that isn't some horrific hack built on bison). The downside is that if
there's a bug in someone else's code, it becomes a bug in your code. :D

------
petecooper
Not working here -- likely hugged to death -- so Google cache:

[https://webcache.googleusercontent.com/search?q=cache:I3M170...](https://webcache.googleusercontent.com/search?q=cache:I3M170FkOTUJ:https://www.openssl.org/news/secadv/20160503.txt+&cd=1&hl=en&ct=clnk&gl=uk)

Edit: spelling.

~~~
greglindahl
Or the Internet Archive:

[https://web.archive.org/web/20160503160435/https://www.opens...](https://web.archive.org/web/20160503160435/https://www.openssl.org/news/secadv/20160503.txt)

------
kafka99
Looks like the "negative zeroes" patch (commit in
[https://mta.openssl.org/pipermail/openssl-
commits/2015-April...](https://mta.openssl.org/pipermail/openssl-
commits/2015-April/000906.html)) was never introduced in debian and ubuntu?

~~~
kafka99
I was indeed right :( The danger of only backporting security fixes. But it's
in the patch now:

[http://www.ubuntu.com/usn/usn-2959-1/](http://www.ubuntu.com/usn/usn-2959-1/)

------
jjawssd
What's the status of this bug for LibreSSL? (LibreSSL is used in OS X 10.11+)

~~~
slasaus

        OpenSSL announced several issues today that also affect LibreSSL.
    
        - Memory corruption in the ASN.1 encoder (CVE-2016-2108)
        - Padding oracle in AES-NI CBC MAC check (CVE-2016-2107)
        - EVP_EncodeUpdate overflow (CVE-2016-2105)
        - EVP_EncryptUpdate overflow (CVE-2016-2106)
        - ASN.1 BIO excessive memory allocation (CVE-2016-2109)
    
        Thanks to OpenSSL for providing information and patches.
    

[http://marc.info/?l=openbsd-
announce&m=146228598930416&w=2](http://marc.info/?l=openbsd-
announce&m=146228598930416&w=2)

[https://twitter.com/bob_beck/status/727478594591543296](https://twitter.com/bob_beck/status/727478594591543296)

------
FiloSottile
My understanding of the padding oracle vulnerability so far, mainly from the
patch [0]: it's possible to make a "valid" message that has the pad length
byte higher than maxpad (total_length - digest_length - 1) [1]. If you make it
high enough, I think you'll push the offset used in the constant time
comparison masks enough below 0 to entirely skip the MAC check [2]. But then
your entire plaintext will have to match the pad byte to pass the check, and I
think you can use that as a padding oracle.

In other words, constant time programming, which by definition means that you
have to behave normally even if your offsets go negative, is HARD. (And when
you don't put comments ANYWHERE, it's even harder.)

[0]:
[https://github.com/openssl/openssl/commit/70428eada9bc4cf314...](https://github.com/openssl/openssl/commit/70428eada9bc4cf31424d723d1f992baffeb0dfb)

[1]:
[https://github.com/openssl/openssl/blob/70428eada9bc4cf31424...](https://github.com/openssl/openssl/blob/70428eada9bc4cf31424d723d1f992baffeb0dfb/crypto/evp/e_aes_cbc_hmac_sha1.c#L583)

[2]:
[https://github.com/openssl/openssl/blob/70428eada9bc4cf31424...](https://github.com/openssl/openssl/blob/70428eada9bc4cf31424d723d1f992baffeb0dfb/crypto/evp/e_aes_cbc_hmac_sha1.c#L742-L766)

For the record, there is nothing Go or Rust could have done here. The bug is
caused by having to write code that runs in constant time, by employing masks
and behaving in exactly the same way irrespective of the pad value. If you
want to blame the design of something, blame Mac-then-Encrypt in TLS 1.0.

See also The Cryptographic Doom Principle [3].

[3]: [https://moxie.org/blog/the-cryptographic-doom-
principle/](https://moxie.org/blog/the-cryptographic-doom-principle/)

EDIT: Interestingly, this was found with TLS-attacker [4], a new framework to
analyze, test and attack TLS libraries. Finding it was probably "just" a
matter of sending a plaintext made entirely of the same right byte value, and
noticing that the MAC check passes when it should not. However, so far we
didn't have any tool or testsuite (which I'm aware of) to perform this kind of
checks.

[4]: [https://github.com/RUB-NDS/TLS-Attacker](https://github.com/RUB-NDS/TLS-
Attacker)

IMPACT [EDIT]: to sum up, if a client uses AES-CBC to connect to a server with
AES-NI support, a MitM can recover at least 16 bytes of anything it can get
the client to send repeatedly, together with attacker-controlled data (think
Cookies or such, using Javascript cross-origin requests).

~~~
tptacek
That's a second-order padding attack, in the same sense that an integer
overflow most often creates a second-order buffer overflow: a first bug
transitions your program to a state where a second bug --- very exploitable,
and one the program tried to guard against --- is revealed.

What's interesting about crypto to me is the prospect that every common crypto
flaw has second- and third- order variants that we will not find out about for
many years, the same way we've barely now got a grip on the interaction
between C integers and buffer counting.

------
solarengineer
Does anyone know if there is an SSL specification somewhere? One could then
start to write tests at various levels to ensure compliance with the
specification. This test suite could then be considered a compatibility test
suite as well.

~~~
lmm
The spec generally only specifies the correct behaviour, not what the program
should be doing with e.g. malformed ASN.1.

------
Filligree
These are all errors that would be impossible in a language with, oh, bounds
checking.

There may be ranges of security-critical code that make sense to write in C,
for example ensuring that algorithms run in constant time, although with
modern compilers I have difficulty trusting that the compiler won't
accidentally optimize away the constant-time-ness.

Surely ASN.1 encoding isn't part of that range, however?

~~~
pjmlp
Hoare quote during Turing award in 1981:

"The first principle was security: The principle that every syntactically
incorrect program should be rejected by the compiler and that every
syntactically correct program should give a result or an error message that
was predictable and comprehensible in terms of the source language program
itself. Thus no core dumps should ever be necessary. It was logically
impossible for any source language program to cause the computer to run wild,
either at compile time or at run time. A consequence of this principle is that
every occurrence of every subscript of every subscripted variable was on every
occasion checked at run time against both the upper and the lower declared
bounds of the array. Many years later we asked our customers whether they
wished us to provide an option to switch off these checks in the interests of
efficiency on production runs. Unanimously, they urged us not to - they
already knew how frequently subscript errors occur on production runs where
failure to detect them could be disastrous. I note with fear and horror that
even in 1980, language designers and users have not learned this lesson. In
any respectable branch of engineering, failure to observe such elementary
precautions would have long been against the law."

\-- C.A.R. Hoare, Communications of the ACM, 1981

~~~
jftuga
C.A.R. Hoare was the author of the Quicksort algorithm in 1959.

~~~
masklinn
C.A.R. Hoare is both still alive and the author of much more than just
Quicksort.

------
cm3
Off-topic but given how many programs link against OpenSSL and that in some
scenarios statically linked binaries are preferable, I've been wondering if
there's a Linux distro that works like OCaml's opam, namely rebuilding
everything that depends on something that just got updated. Is there such a
distro?

------
zymhan
It's not a great bug, but I think it would require a very particular set of
circumstances to arise:

> ... _only certificates with valid signatures_ trigger ASN.1 re-encoding and
> hence the bug. Specifically, since OpenSSL's default TLS X509 chain
> verification code verifies the certificate chain from root to leaf, TLS
> handshakes could only be targeted with valid certificates issued by trusted
> Certification Authorities.

However it does seem like a great exploit method for malware, using legit
signed certificates that allow overwriting memory just by parsing the cert.

------
josteink
Again? Am I the only one calling this the rule, not the exception at this
point?

This is where I want the Rust-guys (or D or whatever) to be. "Hey guys. A drop
in Libre/Open-SSL replacement, written in rust. Guaranteed to be free of all
those security advisories you keep getting on a monthly basis these days".

That's when people will start taking C-replacements like Rust seriously. Step
up your game, guys :)

------
Mojah
Mirrored here, in case official site collapses:
[https://marc.ttias.be/openssl-
announce/2016-05/msg00002.php](https://marc.ttias.be/openssl-
announce/2016-05/msg00002.php)

------
tajen
Sorry for the noob question, but how do you ensure a Debian installation is
always updated with the latest security patches? Do you just run `apt-get
upgrade` everyday? Isn't there a risk of breaking things?

~~~
steveklabnik
I use Debian.

If you're running stable, you should be able to upgrade every day, and nothing
will break. that's the purpose of stable; it really only adds security fixes.

