6 ms·
OpenSSL Security Advisory [7th February 2023]
- some_furry 4y agoAre these dates correct? An initial report of a possible timing side channel was made on 14th July 2020 by Hubert Kario (Red Hat). A refined report identifying a specific timing side channel was made on 15th July 2022 by Hubert Kario. The fix was developed by Dmitry Belyavsky (Red Hat) and Hubert Kario. If so, it's interesting that it took exactly 2 years and 1 day for the refined report. EDIT: By interesting I just mean "an amusing coincidence" or "possibly a typo", nothing weird.
- tptacek 4y agoWhy is that interesting?
- Rafuino 4y agoIs taking 2 years to address a vulnerability normal?
- tptacek 4y agoMaybe in this case! You can look at P1v15 RSA and assume that there might be some kind of behavior oracle, which is definitely not the same thing as demonstrating that there is a viable oracle. A problem with P1v15 in general is that you have to mitigate these kinds of covert channels directly. But I assume the comment above was suggesting there was something more interesting than the magnitude of the lag.
- some_furry 4y ago> But I assume the comment above was suggesting there was something more interesting than the magnitude of the lag. Nothing insidious, just thought maybe it could have been a typo. But if not, then it's just an amusing coincidence. Taking 2 years to demonstrate the impact of a difficult or strange cryptographic bug isn't really that interesting in and of itself.
- tptacek 4y agoRight, especially in this case where you can almost just go from TLS library to TLS library saying "hm, this implements P1v15, probably has a timing channel" to get credit for the eventual finding. :)
- some_furry 4y agoRight. In a lot of cases "this implements RSA" and "this wasn't written by Thomas Pornin" is enough to suspect a timing channel. Writing a proof of concept for one is at least an order of magnitude more challenging; at least in my experience. (I am way better at mitigation than exploit development.)
- tptacek 4y agoEverybody is!
- some_furry 4y agoGood to know! (I thought maybe this was just my own biases or weaknesses showing. I've been trying to work on it this year when I have time.)
- dottedmag 4y agoIt took 2 years to find out that a potential vulnerability actually exists. There's a lot of potential vulnerabilities that may or may not actually be exploitable.
- midasuni 4y ago“I think there may be a bug but I can’t reproduce it” is quite common I just managed to repot use a bug in a vision system that I saw in august. Finally managed to reproduce it mostly last week.
- deleted 4y ago[deleted]
- midasuni 4y ago2 year was frequently the length of ssl certificates (they’ve since dropped to 1 year) Or maybe it’s a coincidence.
- mg_at_fork-pl 4y agoIt was never 2 years as it's not 1 year now. It's specified in days (397 currently, 825 and 1185 days before).
- tialaramex 4y agoFor a long time it was months. The original BRs say 60 months (ie 5 years) and then moving to 39 months in 2015. That 1185 days you listed wasn't ever actually in a written document, it's how Chromium browsers generously estimate 39 months. But yes, none of it matters any more. Apple insisted on 398 days, they decided it is a compliance issue, so all legit leaf certificates in the Web PKI that haven't expired have a maximum lifespan of 398 days. People tend to think about it as a year or two years because the way a for-profit CA used these limits was to sell annual certificates but allow early renewal without losing out. Say you bought a cert on June 10th 2022, this year as the end of May approaches you get an email (In reality use automation, please) saying hey, you should renew soon. You can pay up on 29th of May, you get a new certificate which expires on... June 10th 2024. They couldn't do that if the rules didn't allow enough extra days.
- nekoashide 4y agoThe CA/B forum lost a lot of credibility with me, the vote failed and it took a single member (Apple) to tell everyone else that they were going to ignore the vote and proceed anyways. No debate, no re-vote, no giving anyone any extra time or warning.
- tptacek 4y agoThat's how it should work: the major browser vendors and their root programs should be calling the shots. Participation in CA/B is a favor they do the CA industry, nothing more. The rise of activist browser root programs correlates with essentially everything good that has happened in the WebPKI.
- some_furry 4y agoIt's interesting because it looks like it could be a typo on the year (2022 -> 2020), if the date turns out to not be correct. That's all.
- deleted 4y ago[deleted]
- kroeckx 4y agoYes, the dates are correct.
- stabbles 4y agoA few more CVEs and we're at OpenSSL 1.1.1z, followed by v1.1.1.za, and it is going to break some package manager that in a certain locale orders versions as 1.1.1.za > 1.1.1z, and its users will be stuck on a vulnerable version.
- Flocular 4y agoopenSSL 1.1.1 is EOL 2023-09-11 which is likely to be the bigger problem for random-distro-XYZ
- deleted 4y ago[deleted]
- formerly_proven 4y agoThese pretty much all just look like the usual legacy crypto horror show bugs.
- l33t233372 4y agoCan you elaborate?
- blibble 4y agotrying to parse ASN.1/X.509 in C is, to put it mildly: error prone
- cryptonector 4y agoNot if you have an ASN.1 compiler and library, but otherwise yes. OpenSSL has hand-coded templates that correspond to ASN.1 modules for PKIX. That hand-coding can have mistakes, but otherwise the OpenSSL template system is pretty solid. Here we had a mistake in that hand-coding. If they had an ASN.1 compiler then that wouldn't have happened because they could have just compiled the modules from RFC 5280.
- topspin 4y agoOne type error, one timing attack and six memory safety problems. Defect ratio checks out.
- lucb1e 4y agoRatio of what to what? Do you mean the number of bugs one would expect to find in a modern implementation (the former two) as a ratio to the number of bugs one finds in old C code (all of the above)?
- topspin 4y agoBasically. Microsoft and Google have both analyzed software defects and claimed that memory safety violations account for ~70%. I don't have time to dig up citations atm, but it's not hard to find. I think the Google results are 'security' related defects whereas the Microsoft results are all defects, but look it up yourself.
- lucb1e 4y agoNo need, I had the same initial reaction as I scrolled through the list, going from "oh that's a lot of security issues... and virtually all C issues, too... ugh why do we still do this"
- mynameisash 4y agoFrom Microsoft[0]: "As we’ve seen, roughly 70% of the security issues that the MSRC assigns a CVE to are memory safety issues." And from Google[1]: "memory safety bugs continue to be a top contributor of stability issues, and consistently represent ~70% of Android’s high severity security vulnerabilities." [0] https://msrc-blog.microsoft.com/2019/07/22/why-rust-for-safe-systems-programming/ https://msrc-blog.microsoft.com/2019/07/22/why-rust-for-safe... [1] https://security.googleblog.com/2021/04/rust-in-android-platform.html https://security.googleblog.com/2021/04/rust-in-android-plat...
- deleted 4y ago[deleted]
- KennyBlanken 4y agoA reminder that LibreSSL exists and has a fraction of the problems OpenSSL does. https://www.libressl.org/ https://www.libressl.org/
- flangola7 4y agoWhy isn't it used more?
- colmmacc 4y agoI love LibreSSL and what they represent, but neither LibreSSL nor BoringSSL target all platforms or compatibility with OpenSSL, which can be a bit of a challenge ... and I don't think LibreSSL is likely to have FIPS certification. At the AWS cryptography group, we've open-sourced our libcrypto - https://github.com/awslabs/aws-lc https://github.com/awslabs/aws-lc - which essentially tries to use the best from Google's BoringSSL, OpenSSL (from 1.1x , not 3.x) , our own code, and formal verification and does target a broad set of platforms and is our FIPS module. We're at about 95% OpenSSL compatibility right now, it "just works" for a lot of applications, and I expect we'll get near-full compatibility this year as we switch more and more of our own systems to using it internally. We don't promote it broadly, and it's not intended to compete with OpenSSL - but it's a may be an interesting option for some to consider.
- mappu 4y agoIs your FIPS .dll/.so publicly available? It's surprisingly hard to get FIPS crypto in Golang on Windows.
- irogers 4y agoThis seems relevant: Future of Memory Safety Challenges and Recommendations https://advocacy.consumerreports.org/wp-content/uploads/2023/01/Memory-Safety-Convening-Report-1-1.pdf https://advocacy.consumerreports.org/wp-content/uploads/2023... """ Case Studies 1. The Python cryptographic authority is one of the most widely used cryptography libraries in the Python ecosystem. Many of the tools are largely built on OpenSSL. The popular cryptography library is written in C. About two years ago, the maintainers started the process of migrating some of their dependence on OpenSSL away from that to their own Rust code, particularly starting with areas around certificate parsing and parsing of other structures. These are some of the most classical places to find memory safety vulnerabilities in C libraries, and they wanted to mitigate the risk that they were having by relying on OpenSSL. Another benefit was getting huge performance improvements, because the greater safety guarantees they were getting from the language allowed them to be more aggressive in doing things like not copying memory. Specifically, the safety guarantees of Rust mean that one can easily represent structures like X.509 certificates as an array of bytes, and then a parsed structure containing pointers into the original array. ... """
- deleted 4y ago[deleted]
- LinuxBender 4y agoUpdates for this were released on Alpine and Void Linux. I assume the same for most other distributions? Alpine: OpenSSL 3.0.8 7 Feb 2023 (Library: OpenSSL 3.0.8 7 Feb 2023) Void: OpenSSL 1.1.1t 7 Feb 2023
- Nimi 4y agoIs there a writeup describing the exact timing side channel? The advisory states that the vulnerability affects all RSA padding modes, which seems to imply non-constant-time BigNum operations. However, OpenSSL implemented RSA blinding even before the fix, which is supposed to prevent those class of problems. So this should be interesting :-) (I did find the commit fixing it, but it's huge, and I can't follow the change: https://github.com/openssl/openssl/commit/b1892d21f8f0435deb0250f24a97915dc641c807 https://github.com/openssl/openssl/commit/b1892d21f8f0435deb...
- 1letterunixname 4y agoKeep doing the same thing and expecting a different result is one of 2 possibilities. No surprise and it will keep happening. Let me enumerate: - Governance is awful - They pile in every feature imaginable - ... with insufficient testing - Insist on throwing everything imaginable together in one mega package - Code style is messy - Aren't all that organized - Release unbaked features randomly - Bow to the whims of emergency asks by random governments and corporations It's why OpenBSD forked and took a blowtorch to half of their junk. Don't use OpenSSL and not expect to be pwned by any one of an endless stream of 0days or CVEs.