14 ms·
OpenSSL Security Advisory
- jamescun 6y agoSo 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 6y agoCorrect, but only in the rare case where the "purpose" value has been overridden to be empty.
- xbar 6y agoThe path to greater Security is bumpy.
- brian_herman 6y agohttps://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3450 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3450
- d4mi3n 6y agoBoth 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 6y 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 6y 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 ?
- tomputer 6y agoAccording 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-use-ssl-tls-renegotiation/230327#230327 https://security.stackexchange.com/questions/24554/should-i-...
- tyingq 6y 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.
- earthboundkid 6y agoIf 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.
- LeonM 6y agoJust 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.
- dt3ft 6y agoIf only the billionaires would listen to you... (Mind you, I fully agree with you here.)
- planckscnst 6y agoLike s2n? https://aws.amazon.com/blogs/security/introducing-s2n-a-new-open-source-tls-implementation/ https://aws.amazon.com/blogs/security/introducing-s2n-a-new-...
- cryptonector 6y agoThat doesn't replace all the PKIX bits from OpenSSL.
- dijit 6y agoThere 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.
- dralley 6y agoWonder if LibreSSL is affected
- tptacek 6y agoLibreSSL is a fork of 1.0.1, so you can read this security advisory and get a good guess.
- 77pt77 6y agoProbably 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 6y agoChanges between 1.1.1j and 1.1.1k [25 Mar 2021] https://www.openssl.org/news/cl111.txt https://www.openssl.org/news/cl111.txt
- polack 6y agoCan someone translate this for us dummies. Am I at risk of the DoS attack if I have TLSv1.2 enabled in Nginx?
- inbx0 6y agoAfaik Nginx doesn't do TLS renegotiation so I think you're safe. Disclaimer: I know nothing.
- petecooper 6y agoThis was my understanding, too. I checked: http://nginx.org/en/CHANGES http://nginx.org/en/CHANGES >Changes with nginx 1.13.0 >Change: SSL renegotiation is now allowed on backend connections.
- juddgaddie 6y agohttps://stackoverflow.com/a/20001598/843116 https://stackoverflow.com/a/20001598/843116 Looks like it since 0.7.64 or 0.8.23.
- formerly_proven 6y agoThe backend has easier ways to DoS though. Like rejecting connections.
- mwaitjmp 6y agoDoes anyone know about apache?
- throwaway823882 6y agoIt depends on the version of apache and openssl. Check the version of openssl that your apache binary is dependent on. All versions of 1.1.1 before 1.1.1k are vulnerable. ubuntu:~$ dpkg -s apache2-bin | grep ^Depends | sed -e 's/, /\n/g' | grep libssl | awk '{print $1}' | xargs dpkg -s | grep ^Version Version: 1.1.1j-1+ubuntu18.04.1+deb.sury.org+3 First try to just upgrade openssl on your system. Check the package's changelog (ex: http://changelogs.ubuntu.com/changelogs/pool/main/o/openssl/openssl_1.1.1f-1ubuntu4.2/changelog http://changelogs.ubuntu.com/changelogs/pool/main/o/openssl/...) to see if a fix has been backported into it, the version number may not indicate it. If you can't tell, try to install an older 1.0.x version. Then restart apache. (The magic of dynamic libraries... it'll be fun when Go's ssl library has a bug) If that doesn't work, try configuring SSLOptions -OptRenegotiate and then point ssllabs at it to see if reneg is disabled. If that doesn't work, recompile apache against a not-vulnerable version of openssl. Maybe the easiest way to do that is take the Dockerfile (https://github.com/docker-library/httpd/blob/master/2.4/Dockerfile https://github.com/docker-library/httpd/blob/master/2.4/Dock...), take out libssl-dev, compile a specific openssl version, then link against it.
- chrisweekly 6y agoTLDR - upgrade to 1.1.1k.
- yalogin 6y agoHow 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?
- tptacek 6y agoOpenSSL is extensively tested. These bugs are just hard to find.
- 77pt77 6y agoIs it really extensively tested? Should one even write these kinds of libraries in C?
- yabadubakta 6y agoOh great, here we go again... I mean, which OS is available in something other than C? Frankly, C has gotten us quite far in the systems engineering space. No matter what language, bugs will surface. Starting over on the hype-train isn’t always the best idea!
- tptacek 6y agoIn an ideal world, if you could get the same calibre of talent patrolling the Rust port of OpenSSL and everyone using it, of course you'd want the Rust version. We live in a fallen world. For a lot of software, the Rust-Go/legacy-C decision is trivial; you'd always take the Rust or Go. But OpenSSL is a tricky case and you can see why in today's announcement: there's a crasher memory corruption problem (but you can crash Rust programs too! today's bug is like a bad "unwrap"). But the first bug is an X.509 logic problem and I don't believe any practical language forecloses on those. Meanwhile: OpenSSL gets a lot of attention and has a lot of built-up institutional knowledge that other libraries don't. I probably trust it more than I trust any of the other C-language TLS libraries.
- tedunangst 6y ago
- bombcar 6y agoIt 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
- flatiron 6y agohttps://launchpad.net/ubuntu/+source/openssl/1.1.1f-1ubuntu2.3 https://launchpad.net/ubuntu/+source/openssl/1.1.1f-1ubuntu2... it address 3449, so they backported the fix to 1.1.1f
- lathiat 6y agoSee also: https://ubuntu.com/security/notices/USN-4891-1 https://ubuntu.com/security/notices/USN-4891-1
- dt3ft 6y 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 6y agoThe commit with fix: https://github.com/openssl/openssl/commit/2a40b7bc7b94dd7de897a74571e7024f0cf0d63b https://github.com/openssl/openssl/commit/2a40b7bc7b94dd7de8...
- flatiron 6y agothats the first fix, here's the null pointer deference: https://github.com/openssl/openssl/commit/02b1636fe3db274497304a3e95a4e32ced7e841b https://github.com/openssl/openssl/commit/02b1636fe3db274497...
- CrazyPyroLinux 6y agoNot a Rust troll (never used it) but would this be one of those things Rust would prevent?
- tptacek 6y agoEhh, sort of. This is a NULL pointer read; it's a crasher that can't be further weaponized. Approximately the same thing happens in Python, Javascript, Java, and Go when you mis-handle a nil value. Rust goes through some trouble to avoid nil values altogether, and it's great. But in practice, applying matching and iflets to every return value everywhere makes for very noisy code (I mean, Rust is already very noisy, but bear with me), so the idiom in the language is to call "unwrap" on Option and Result values that are "known" to be safe. A mishandled "unwrap" will do approximately the same thing to your program as dereferencing a NULL pointer will. Rust helps here a lot, more than most other languages. It does not foreclose on this kind of bug, though, the way it (and other memory safe languages) foreclose on other memory corruption vulnerabilities. (This is notable not the case for NULL pointer _writes_, which occasionally can be weaponized. Use Rust in preference to C.)
- richardwhiuk 6y ago`?` would be the natural thing to do in Rust, rather than unwrap.
- 0x0 6y agoDebian patch is out: https://security-tracker.debian.org/tracker/DSA-4875-1 https://security-tracker.debian.org/tracker/DSA-4875-1
- psanford 6y agoHere's Ubuntu's: https://ubuntu.com/security/notices/USN-4891-1 https://ubuntu.com/security/notices/USN-4891-1
- laurent92 6y agoIsn’t the vulnerability fixed in 1.1.1j, not 1.1.1d? And “j” is still in the “testing” repo.
- throw0101a 6y ago1.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.
- nijave 6y agoi.e. backported (very common with long term support distros esp Red Hat)
- lucb1e 6y agoSo 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 6y 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 6y agoDoes 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
- spockz 6y agoMy 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 6y agoIf 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.
- spockz 6y agoOk. 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 6y agoEnvoy comes with ssl support and it uses the google variant of openssl (boringssl).
- spockz 6y agoAh 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.
- tomputer 6y agoIs 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 6y agoSend a line consisting of a single 'R' character. https://www.openssl.org/docs/man1.1.1/man1/openssl-s_client.html#CONNECTED-COMMANDS https://www.openssl.org/docs/man1.1.1/man1/openssl-s_client....
- josteink 6y agoAny idea if this impacts OpenWRT as well? I haven't seen anything on their security advisory feed yet.
- perryh2 6y agoDoes 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 https://github.com/terorie/cve-2021-3449
- bombom06 6y agoHow can I check if X509_STRICT mode is enabled or not?