OpenSSL Security Advisory

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

by arkadiyt • 5 years ago

329 141 5 years ago

jamescun• 5 years ago

So if I am reading this right, in addition to a null dereference, turning on strict certificate validation actually disabled the check asserting that non-CA certificates cannot issue other certificates?

AlphaWeaver• 5 years ago

Correct, but only in the rare case where the "purpose" value has been overridden to be empty.

xbar• 5 years ago

The path to greater Security is bumpy.

brian_herman• 5 years ago

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3450

d4mi3n• 5 years ago

Both of these vulnerabilities are problematic, though it’s some comfort that only one of them exists with the default OpenSSL configuration.

DoS attacks are problematic, though I’m wondering what creative uses attackers will find for buggy certificate chain verification.

koolba• 5 years ago

An OpenSSL TLS server may crash if sent a maliciously crafted renegotiation ClientHello message from a client. If a TLSv1.2 renegotiation ClientHello omits the signature_algorithms extension (where it was present in the initial ClientHello), but includes a signature_algorithms_cert extension then a NULL pointer dereference will result, leading to a crash and a denial of service attack.
A server is only vulnerable if it has TLSv1.2 and renegotiation enabled (which is the default configuration). OpenSSL TLS clients are not impacted by this issue.

TLS Renegotiation strikes again!

One of the best parts of TLS 1.3 is that they completely scrapped it. So, IIUC, if you're running only TLS 1.3 then the NULL deference for the (enabled by default) feature in TLS 1.2 will not impact you.

Also a lot of end user facing software such as nginx has renegotiation explicitly disabled so hopefully this won't be particularly far reaching.

xfalcox• 5 years ago

Also a lot of end user facing software such as nginx has renegotiation explicitly disabled so hopefully this won't be particularly far reaching.

Do you know if the same if true for HAProxy ?

tomputer2• 5 years ago

According the the link below: "All major software disabled renegotiation by default since as far as 2009 (nginx, haproxy, etc...)."

https://security.stackexchange.com/questions/24554/should-i-...

tyingq• 5 years ago

"An OpenSSL TLS server may crash if sent a maliciously crafted renegotiation ClientHello message from a client. If a TLSv1.2 renegotiation ClientHello omits the signature_algorithms extension (where it was present in the initial ClientHello), but includes a signature_algorithms_cert extension then a NULL pointer dereference will result, leading to a crash and a denial of service attack."

That sounds like enough info that exploits will be out pretty soon. And it sounds like most software that uses OpenSSL would crash. So, guess I'm expecting broad DoS incidents soon.

earthboundkid3• 5 years ago

If the cloud companies just paid a team of five people 200K each to spend a year rewriting OpenSSL from scratch, they would save multiple millions in scrambling to deploy bug fixes.

planckscnst• 5 years ago

Like s2n?

https://aws.amazon.com/blogs/security/introducing-s2n-a-new-...

cryptonector8• 5 years ago

That doesn't replace all the PKIX bits from OpenSSL.

dijit3• 5 years ago

There have been attempts of repairing openssl. Every time it's a big problem due to lack of adoption.

LibreSSL would solve a lot of the surface area problems OpenSSL has, but people cling to OpenSSL under the guise that "a lot has improved" and of course that change is hard.

The point I'm trying to make is that there _are_ better SSL libraries, but none have the adoption of openssl, and adoption has inertia; nobody is going to go out of their way to avoid OpenSSL because a bug in openssl is not their fault.

Just like AWS's availability, people work on the premise that if AWS is down (or OpenSSL has bug!) then everyone is affected and therefore they can't be blamed.

jamal-kumar3• 5 years ago

I've been making personal moves towards libressl and openbsd in general. there's just way less friction involved in maintaining those servers vs my linux ones running stuff like this that constantly leaves me hitting up my clients like 'yeah we need to do this at midnight'

If libressl is affected by this too I would be incredibly surprised. They really did do a great job of removing all the bad stuff for something that just works as a drop-in replacement compatible with scripts and everything.

dadrian• 5 years ago

LibreSSL hasn't improved anything. Deleting all the code that was #ifdef'd out for old platforms might make you feel good, but it doesn't actually help security because none of the code was compiled anyway.

rtpg• 5 years ago

Serious question: who are the decision makers on "using OpenSSL" vs other stuff? It feels like most application level people will be using whatever gets packaged with whatever framework/HTTP server they use, so shouldn't there be relatively few people to convince here? Or is that a big misread of the situation

dspillett• 5 years ago

There have been attempts of repairing openssl. Every time it's a big problem due to lack of adoption.

If the repair is a drop-in replacement then the issue shouldn't be too bad. If new one does prove to be more stable in terms of needing security updates to be rolled out, then people will start to adopt it to save the time.

Of course the problem with that is the new version will need to be entirely feature complete from day one, and surprisingly bug free for something of that size or confidence will be too low, and track changes in OpenSSL for long enough until it becomes the de facto standard instead.

77pt774• 5 years ago

A variant of

No has ever been fired for choosing IBM/Microsoft/Oracle/etc.

gregoriol• 5 years ago

Doing security is hard, it wouldn't be as easy as you describe to replace it! OpenSSL has some issues from time to time, but like any code that exists. However, it also benefits from billions of real-world use-cases and deployments, research work and analysis, that would be very hard to reproduce on an entierly new code base.

rapsey2• 5 years ago

BoringSSL is now very widely used. There is also rustls (fully safe rust code) with OpenSSL API available.

earthboundkid3• 5 years ago

Yeah. Thinking about it seriously, the problem is that if you do a “drop in replacement” you’ve just recreated all the existing bugs. If you don’t do a drop in replacement, adoption will be poor, see BoringSSL etc. It’s sort of no-win.

LeonM• 5 years ago

Just pay a bunch of talented security researchers to find the bugs. Also donate 200k/year to the OpenSSL team so they have the capacity to fix the bugs whenever found.

dt3ft2• 5 years ago

If only the billionaires would listen to you... (Mind you, I fully agree with you here.)

justapassenger2• 5 years ago

Complete rewrite of decades old software that’s powering all of world is many orders of magnitude more expensive than what you suggest. And only thing you’re guaranteed is bazillions of incompatibilities, bugs, security issues and other horrible stuff.

Especially with such a sensitive thing like crypto. Just off the top - you have to be really careful with implementation to prevent timing attacks. And that’s just one of many hundreds things you need to care about.

IgorPartola• 5 years ago

But what if we rewrite it all in Rust bugs become impossible! /s

jariel2• 5 years ago

I understand the sentiment - but this may not be the case.

A lot of software was written a long time ago with as-of-yet-unestablished good practices.

Almost no concern for security or anything else.

I wonder if they actually took really good best practices both for security and just software in general, used something like Rust, used a very open dev process with a lot of eyes on it - and somehow avoided the feature creep / political feature orientation trap ... if it could not only be re-written, but made more simple.

Maybe it would take 5 years (1 design 1 develop 3 deploy and test) but it would still be worth it.

I believe that security is a much worse problem than it needs to be, because everything we depend on today was designed without much security in mind.

toast0• 5 years ago

If you were going to rewrite OpenSSL, it makes sense to break it into three pieces: ciphers (crypto), protocol, and certificates.

OpenSSL ciphers are generally good, and there's no need to rewrite that.

Certificate and protocol are where most of the tricky bugs would be found.

Protocol is actually not that much code, and a from scratch rewrite that only did TLS 1.2 and 1.3, and only allowed for currently deemed reasonable options wouldn't be too bad to do. Of course, that would eliminate renegotiation, so today's OpenSSL bug wouldn't be possible. I've done a TLS 1.3 client from scratch and it's about a monthish of prototyping, followed by six months to do it right and test and deploy and find bugs and have it audited by a 3rd party and eventually be happy with it. I did the prototyping, another developer did the production code; we did have other developers familiar with TLS to review and assist. I imagine TLS 1.2 would be similar, but having experience from 1.3 would help it along. Server side wouldn't add much, once the session is established everything is the same, it's just having to flip parsing and generating of the handshake pieces.

Certificate/x.509 handling is a beast. I imagine rewriting and testing that would take a long time. You would probably find bugs in other verifiers while you're doing it if you cross test though. You could save a little by limiting to commercially available certificate options and limiting verification modes, but it's still a lot. ASN.1 parsing might be significantly nicer not in C though.

wglb• 5 years ago

Seems like everyone has forgotten the rewrite of Apache that led to the bug flood that was 2.0

indymike• 5 years ago

Nope, they'd just create new software with different bugs that have not been discovered yet. Then we'd all be scrambling to fix those bugs.

wizeman5• 5 years ago

Not if the implementation is formally verified, like miTLS [0] and EverCrypt [1]. Parts of the latter were integrated into Firefox, which even provided a performance boost (10x in one case) [2].

I think what is needed is something like EverCrypt but for TLS. Or in other words, something like miTLS but which extracts to C and/or Assembly, to avoid garbage collection and for easy interoperation with different programming languages (preferably including an OpenSSL-compatible API for backwards compatibility).

[0] https://mitls.org/ [1]: https://hacl-star.github.io/HaclValeEverCrypt.html [2]: https://blog.mozilla.org/security/2020/07/06/performance-imp...

dralley• 5 years ago

Wonder if LibreSSL is affected

tptacek12• 5 years ago

LibreSSL is a fork of 1.0.1, so you can read this security advisory and get a good guess.

77pt774• 5 years ago

Probably not affected since this bug was introduced after version 1.0.1 that is the version where the fork happened.

Starting from OpenSSL version 1.1.1h a check to disallow certificates in the chain that have explicitly encoded elliptic curve parameters was added as an additional strict check.
An error in the implementation of this check meant that the result of a previous check to confirm that certificates in the chain are valid CA certificates was overwritten. This effectively bypasses the check that non-CA certificates must not be able to issue other certificates.

joseluisq• 5 years ago

Changes between 1.1.1j and 1.1.1k [25 Mar 2021]

https://www.openssl.org/news/cl111.txt

polack• 5 years ago

Can someone translate this for us dummies. Am I at risk of the DoS attack if I have TLSv1.2 enabled in Nginx?

inbx0• 5 years ago

Afaik Nginx doesn't do TLS renegotiation so I think you're safe.

Disclaimer: I know nothing.

petecooper• 5 years ago

This was my understanding, too. I checked:

http://nginx.org/en/CHANGES

Changes with nginx 1.13.0
Change: SSL renegotiation is now allowed on backend connections.

mwaitjmp• 5 years ago

Does anyone know about apache?

chrisweekly• 5 years ago

TLDR - upgrade to 1.1.1k.

yalogin• 5 years ago

How is this not found till now? Doesn't openssl have negative tests? Even if they didn't don't companies have negative tests? Not even one company that relies on openssl have this test?

tptacek12• 5 years ago

OpenSSL is extensively tested. These bugs are just hard to find.

77pt774• 5 years ago

Is it really extensively tested?

Should one even write these kinds of libraries in C?

jeffbee4• 5 years ago

I mean, branch coverage could have fingered this hole in the unit tests, couldn't it? The problem is X509_V_FLAG_X509_STRICT was added in 2004 without any corresponding tests. The project still has decades of debt from past poor practices to pay down.

Pokepokalypse• 5 years ago

. . . the easy ones have been found and fixed. What remains are the hard ones.

bombcar• 5 years ago

It doesn't appear they pre-notified the major distributions - at least I'm not seeing updates already available as normally happens when it is coordinated.

Ubuntu 20.04 just dropped openssl 1.1.1f-1ubuntu2.3

flatiron2• 5 years ago

https://launchpad.net/ubuntu/+source/openssl/1.1.1f-1ubuntu2...

it address 3449, so they backported the fix to 1.1.1f

lathiat• 5 years ago

dt3ft2• 5 years ago

This issue was reported to OpenSSL on 18th March 2021 by Benjamin Kaduk from Akamai and was discovered by Xiang Ding and others at Akamai. The fix was developed by Tomáš Mráz.

Thank you Akamai for reporting this, and thank you Tomáš for fixing this.

Jenk• 5 years ago

The commit with fix: https://github.com/openssl/openssl/commit/2a40b7bc7b94dd7de8...

flatiron2• 5 years ago

thats the first fix, here's the null pointer deference: https://github.com/openssl/openssl/commit/02b1636fe3db274497...

CrazyPyroLinux• 5 years ago

Not a Rust troll (never used it) but would this be one of those things Rust would prevent?

0x0• 5 years ago

Debian patch is out: https://security-tracker.debian.org/tracker/DSA-4875-1

psanford• 5 years ago

Here's Ubuntu's: https://ubuntu.com/security/notices/USN-4891-1

laurent92• 5 years ago

Isn’t the vulnerability fixed in 1.1.1j, not 1.1.1d? And “j” is still in the “testing” repo.

throw0101a• 5 years ago

1.1.1d is fixed if you patch that part of the code.

The version going from "+deb10u4" to "+deb10u6" indicates that there are supplementary changes that the Debian project made on top of the vendor release of 1.1.1d.

Going from 1.1.1d to e, f, g, h, i, or j may introduce other behaviour changes that could be undesirable, so Debian 10 (in this example) is frozen using 1.1.1d and any bugs are dealt with on an as-needed basis.

lucb1e• 5 years ago

So if I understand it correctly, the impact of these two "high" vulnerabilities is:

- if you use the non-default X509_V_FLAG_X509_STRICT flag and use the new openssl 1.1.1h feature to "disallow certificates in the chain that have explicitly encoded elliptic curve parameters" and configure a custom "purpose" value in your software then this second feature (disallowing explicit curve params) was ineffective, or

- if you run a TLS1.2 server and renegotiation is enabled then someone can craft a packet that will crash the server (e.g. Nginx disabled renegotiation in 2009 and seems thus unaffected).

pjungwir• 5 years ago

this second feature (disallowing explicit curve params) was ineffective

Not quite. It would override the previous check about being signed by a valid CA.

I imagine the implementation was something like this:

    is_valid = true;
    is_valid &= signed_by_valid_ca(cert);
    if (check_x509_strict) {
        is_valid = !has_explicitly_encoded_curve_params(cert);
    }
    is_valid &= some_other_test(cert);
    is_valid &= yet_another_test(cert);

And it should have been:

        is_valid &= !has_explicitly_encoded_curve_params(cert);

jacobkg• 5 years ago

Does anyone know the best way to update a mac’s OpenSSL from 1.1.1j to 1.1.1k?

Homebrew seems to still be using 1.1.1j

mastre_2• 5 years ago

Mac's OpenSSL should be LibreSSL 2.8.3 as of Big Sur 11.2.3; for brew openssl you'll have to wait till they update it.

mastre_2• 5 years ago

Update: as of now, homebrew has updated to openssl 1.1.1k.

spockz3• 5 years ago

My biggest gripe is the inability, or my lack of knowledge on how, to enable observability (metrics and events) on the failure cases. Maybe it is possible with recompiling the code but this won’t help if OpenSSL comes packaged in something like envoy.

I want to be able to see metrics of how often which rejection occurred. Preferably even security events for each failed tls connection including peer identity, and the failure reason.

(I’m silently rooting that someone will tell me I’m wrong and shows that it is possible to do the above...)

asveikau• 5 years ago

If you had something with a lot of traffic logging TLS issues I wonder if you would see noise from packets corrupted by hardware that were not caught by the TCP checksum. That or some low, interesting number of users with very badly misconfigured peers, where it's not your responsibility to fix.

I can't recall the exact details. But i remember once logging crypto failures on a high usage app, and it seemed noisy for something like that. Similarly to collecting logs for i/o failures in the field, if you have legit bugs they are often drowned out by issues caused by bad disks.

spockz3• 5 years ago

Ok. From our basic metrics on failed/successful tls connection established, I can conclude we only are dealing with incorrectly configured clients and not from random glitches. Peers keep connecting properly after they have figured out how the first time.

I would expect the events to be rich enough In information to distinguish corruption from really sending incompatible parameters/certs vs checksum failures.

davinci26• 5 years ago

Envoy comes with ssl support and it uses the google variant of openssl (boringssl).

spockz3• 5 years ago

Ah indeed, I was put on the wrong foot because the error messages are similar.

But it has the same downside of being hard to troubleshoot.

tomputer2• 5 years ago

Is it possible to test with openssl s_client if TLS renegotiation is on or off?

I’m also not sure if it is about legacy or secure renegotiation (or both).

yrro• 5 years ago

Send a line consisting of a single 'R' character.

https://www.openssl.org/docs/man1.1.1/man1/openssl-s_client....

josteink• 5 years ago

Any idea if this impacts OpenWRT as well?

I haven't seen anything on their security advisory feed yet.

perryh2• 5 years ago

Does anyone have a PoC? Someone posted this on Github but the git log is squashed and doesn't show the changes they made. https://github.com/terorie/cve-2021-3449

bombom06• 5 years ago

How can I check if X509_STRICT mode is enabled or not?

OpenSSL Security Advisory

Related Stories