OpenSSL Security Advisory

https://www.openssl.org/news/secadv/20160503.txt

by FiloSottile • 10 years ago

259 228 10 years ago

openssl.org

FiloSottile2• 10 years ago

Patch: https://github.com/openssl/openssl/commit/70428eada9bc4cf314...

Advisory mirror: https://gist.github.com/FiloSottile/99ad6b52688f5a1f0a5fa200...

Preliminary analysis: https://news.ycombinator.com/item?id=11621038

CiPHPerCoder6• 10 years ago

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

... I am beyond words.

pjmlp13• 10 years ago

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

petecooper• 10 years ago

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

https://webcache.googleusercontent.com/search?q=cache:I3M170...

Edit: spelling.

greglindahl• 10 years ago

Or the Internet Archive:

https://web.archive.org/web/20160503160435/https://www.opens...

roddux• 10 years ago

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.

pjmlp13• 10 years ago

The sad part is that already in the mid-60's and 70's, in computers much less powerful than the PDP-11, bounds checking wasn't a problem as such.

In the few cases where it was a real problem for the application being written, it could be selectively disabled. Which according to C.A.Hoare in his 1981 speech, most people didn't want to do anyway.

It only became a problem in the industry thanks to C.

krylon3• 10 years ago

Having written C for a living for about two years, I have to admit that a large part of me really likes C. But also, I would have commited unspeakable acts just to have a compiler switch to enable bounds checking, no matter how badly that would have affected performance.

Even when one knows what one is doing - or thinks so, anyway - these errors are so easy to sneak in and such a pain to track down. (Especially since we were using OpenWatcom whose debugger did not show useful data when the program crashed, which is usually the time one needs it the most...)

ams6110• 10 years ago

It wasn't a problem in assembly language? Which was widely used before C became popular.

ArkyBeagle19• 10 years ago

No, it became a problem when 1) microprocessors evolved into being able to do real work 2) Vast hordes of the great unwashed (I'd say even including me ) were vacuumed into the resulting void and 3) tools vendors for languages with better safety furniture were found wanting. Delphi existed but was found wanting. Ada ads were in the back of oh so many magazines. But...

And I'd throw in 4) - the CS industrial complex failed to address this except to rail against it. The first CACM I ever got was the one with "Reflections on trusting trust." If a Haskell or Rust is the answer, it needs to be more interesting. And if you say "but Java", name your second; I will meet you on the field of honor at dawn :)

I personally found "nobody is going to save you; you are on your own" very liberating but perhaps that is unusual. "In order to live outside the law, one must be honest." - Bob Dylan.

Someone12343• 10 years ago

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-wallis2• 10 years ago

This sounds like a witch hunt. Java has horrible security bugs even today.

Bugs can be found in code written in all languages.

zzzcpan• 10 years ago

To be fair, most of the vulnerabilities found in C codebases are preventable with static analysis, bound checking, etc. If you are ok with it getting as slow as Go, you can get similar safety guarantees as well.

0xdeadbeefbabe• 10 years ago

printf("bull crap"); short programs can be secure.

Scea91• 10 years ago

C++ is vastly different animal than C in this case. Most of the problems with C you are implying here are non issues in modern C++.

ArkyBeagle19• 10 years ago

It may be tiresome, but it happens to be true. That something isn't done is not evidence than it cannot be done.

I think 'C'/C++ is the scapegoat for a massive cultural failing and have thought that for going on 25 years now.

frewsxcv• 10 years ago

In case anyone wants to learn about an effort to incrementally port some of the BoringSSL (fork of OpenSSL) primitives to Rust:

https://github.com/briansmith/ring

If anyone is looking to contribute and wants a "good first task", here are some tasks:

https://github.com/briansmith/ring/issues?q=is%3Aopen+is%3Ai...

Help is greatly appreciated :)

lambda4• 10 years ago

Of particular interest here is also webpki:

https://github.com/briansmith/webpki

Which is designed to validate TLS certificates. This is doing the ASN.1 parsing and signature verification in a zero-copy, memory safe way, built on top of ring for the core crypto primitives.

Now, this isn't a full implementation of what you would need for replacing OpenSSL for certificate handling (and also isn't yet complete); in particular, this is extremely limited in scope as only being for client-side certificate verification. This particular OpenSSL issue was when parsing and re-encoding certificates, which is out of scope for webpki. But it is a good starting point for demonstrating memory-safe and efficient handling of complex tasks like parsing and verifying of TLS certificates.

sebcat2• 10 years ago

Maybe the machine is at fault? Maybe the problem is not with C, but with a hardware architecture that does not offer finer granularity than page allocations? What if everything returned from malloc() would be bound checked by hardware? What if, instead of overwriting a malloc_chunk or the saved value of the instruction pointer, a hardware interrupt would be raised? Maybe the return stack and the parameter stack can be separate? Maybe someone solved these problems in hardware before the majority of us was born?

lmm16• 10 years ago

That wouldn't help. GCC would just compile code that turns off those features, since that would help it do better on benchmarks.

ThisIs_MyName3• 10 years ago

offer finer granularity than page allocations

How the fuck would that work? Today, the page table is cached in a TLB and modern Intel processors only have 1024 entries!

If you have a new entry in the page table for every malloc, dereferencing virtual memory will require a page walk for pretty much every memory access. You can't cache millions of entries.

spc4762• 10 years ago

The Intel 432 could do that (1982). Unfortunately, the Intel 432 was also slow and very complex (it's the only architecture I'm aware of that was object oriented at the microcode level).

The Intel 80286 could also do that (some of the features of the Intel 432 found their way into the 80286) but no one who lived through those days wants to return to those days (small, compact, medium, large and huge memory models anyone?).

The Intel 80386 (and really, any Intel CPU that can still execute 16-bit code) can do that. But then you are programming a glorified 80286 and well ... see above.

But okay, you want more details? You have segment registers, CS, DS, ES, SS (and the 80386 give you a few more) that define the base address and limit. To get byte granularity, you are limited to 65536 bytes and you are dealing with a very odd-ball 32-bit address (16-bit segment, 16-bit offset) or a 48-bit address (16-bit segment, 32-bit offset limited to 65,535). If you want more memory per segment, you lose the byte granularity (promoting sloppy coding, etc).

This is not an easy problem to solve.

osweiller2• 10 years ago

While C (and its love-child C++) bizarrely appears high in most synthetic programming popularity rankings, I personally doubt more than 5% of developers (if that) ply their days in it, or have more than a passing competency in it.

Everyone is programming in Java, C#, JavaScript, and so on. Aside from myself, I haven't a single professional peer who develops on C (anecdotal, of course, but this is a pretty big net crossing multiple cities and industries) in any real way.

It just happens to be that much of the most important software is written in it. Maybe there's something in that.

tracker1• 10 years ago

I wouldn't minimize the amount of C(++), or the amount of mis-counting for jobs where C(++) is a desired skill, but not primary in the job role. There are a lot of jobs out there working on embedded systems where C/C+ are king. Though I do hope that Rust gains more traction in that space to avoid certain classes of bugs.

I would guess that most development involves JS, as I would say that most development is directed in web applications of some kind. Though there are backend languages as well. For the types of development jobs I'm used to looking for, I see a lot more C# and Java, with some uptick in Node and Python. Excluding PHP (because shiver).

I have several friends who work in the embedded space, and that is not small by any means.

PeCaN3• 10 years ago

I developed most of my hobby projects in C until recently. It's not as rare as you think. C is a good language to think in.

Lately I've been switching to Ada, which I actually quite recommend if you like C. Shame it never really caught on, but using C libraries from Ada is trivial so there's not much of a library issue in spite of lack of popularity.

ArkyBeagle19• 10 years ago

This is just selection bias - you probably just don't run into 'C' programmers.

ArkyBeagle19• 10 years ago

It's nothing but a path-dependent accident of history.

ArkyBeagle19• 10 years ago

And I think the difficulty of manual memory management is vastly overrated. A bug is a bug is a bug. If OpenSSL is ... safety critical, then it should be treated as safety critical going forward. Tools don't make bugs, people make bugs.

Of course, someone's free to write a replacement for OpenSSL in Rust and see how far that goes.

FWIW, there used to be a rich suite of very respectable ASN.1 verification tools, at least the subset of ASN.1 used in SNMP.

masklinn4• 10 years ago

I think the difficulty of manual memory management is vastly overrated.

And your line of thinking is why we're going on 50 years of empirical evidence that people are terrible at manual memory management, and as with politics there's a pretty small common subset between those who believe themselves competent and those which should be trusted with it.

A bug is a bug is a bug.

An error message is not a misprint is not a denial of service is not a DB penetration is not a crypto break is not a network ownage. "A bug is a bug is a bug" as long as your code is not used by anybody or trusted with anything.

Filligree• 10 years ago

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?

pjmlp13• 10 years ago

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

codezero2• 10 years ago

Making it illegal to write code without bounds checking is an interesting and fun concept to imagine.

jftuga• 10 years ago

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

CiPHPerCoder6• 10 years ago

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

How would that prevent the timing leak that caused Lucky 13 or the padding oracle that resulted from not erroring when the message was too short?

The problem with CVE-2016-2107 (and the vulns that precede it) stems from TLS not using Encrypt-Then-MAC (checking the MAC before checking the padding is less error-prone than checking the padding before the MAC). You can design a cryptographically doomed protocol in any language, even memory-safe ones.

Here's one in Haskell: https://github.com/RNCryptor/rncryptor-hs/issues/2#issuecomm...

Further reading on the Cryptographic Doom Principle: https://moxie.org/blog/the-cryptographic-doom-principle/

pjmlp13• 10 years ago

Yes you can, but you cannot corrupt memory in them and that is already helpful.

lmm16• 10 years ago

Bounds checking would only solve half of the vulnerabilities that break the security of every computer on the Internet, not all of them, so I guess it's not worth bothering with?

solarengineer• 10 years ago

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.

CiPHPerCoder6• 10 years ago

There are numerous RFCs, yes.

theandrewbailey• 10 years ago

The SSL spec (if you can call it that) and everything it depends on is spread over about a dozen or so RFCs. Good luck.

IgorPartola• 10 years ago

This has been discussed to death, and the conclusion is generally that testing for unknown security bugs is not possible (or at least not practical).

lmm16• 10 years ago

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

jbaviat2• 10 years ago

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://llvm.org/docs/LibFuzzer.html

ashitlerferad4• 10 years ago

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

http://lcamtuf.coredump.cx/afl/

jbaviat2• 10 years ago

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

http://lcamtuf.blogspot.fr/2014/11/pulling-jpegs-out-of-thin...

mcs• 10 years ago

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.

cyphar2• 10 years ago

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.

lmm16• 10 years ago

Thrift/Protobuf/etc. are reasonably nice IME.

zeveb• 10 years ago

This is why the SPKI guys, seventeen years ago, made one of their design goals not using ASN.1: https://tools.ietf.org/html/rfc2692 states 'No library code should be required for the packing or parsing of SPKI certificates. In particular, ASN.1 is not to be used.'

They came up with a simple, beautiful representation for certificates. They also came up with a simple, logic, understandable way to think about what certificates can and cannot do.

The world ignored them. RFCs 2692 & 2693 stand as a remarkable example of what could have been.

spc4762• 10 years ago

CBOR (RFC-7049) comes to mind.

FiloSottile2• 10 years ago

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

[1] https://github.com/openssl/openssl/blob/70428eada9bc4cf31424...

[2] https://github.com/openssl/openssl/blob/70428eada9bc4cf31424...

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/

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

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

tptacek2• 10 years ago

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.

zymhan• 10 years ago

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.

jjawssd• 10 years ago

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

jlgaddis• 10 years ago

Saw a tweet from one of the OpenBSD folks saying LibreSSL was also affected by these issues and fixes would be available today. Sorry, not on my laptop at the moment so I can't post a link.

ETA: Source code [0] and binary [1] patches (via M-Tier) are available for OpenBSD.

[0] https://marc.info/?l=openbsd-tech&m=146228598730414&w=2

[1] https://stable.mtier.org/

slasaus• 10 years ago

    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

https://twitter.com/bob_beck/status/727478594591543296

kafka992• 10 years ago

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

kafka992• 10 years ago

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/

nickpsecurity23• 10 years ago

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

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• 10 years ago

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

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

nickpsecurity23• 10 years ago

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.

Mojah• 10 years ago

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

tajen• 10 years ago

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?

steveklabnik5• 10 years ago

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.

teddyh• 10 years ago

Install the “unattended-upgrades” package.

josteink• 10 years ago

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 :)

cm3• 10 years ago

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?

OpenSSL Security Advisory

Related Stories