OpenSSL Security Advisory [7th February 2023] | Hacker News Reader

OpenSSL Security Advisory [7th February 2023]

openssl.org

134 pointsFiloSottile47 comments

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

Why is that interesting?

Is taking 2 years to address a vulnerability normal?

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

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

Right, 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. :)

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

Everybody is!

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

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

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

2 year was frequently the length of ssl certificates (they’ve since dropped to 1 year)

Or maybe it’s a coincidence.

It was never 2 years as it's not 1 year now. It's specified in days (397 currently, 825 and 1185 days before).

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

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

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

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

Yes, the dates are correct.

Is 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/b1892d21f8f0435deb...

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

Updates 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

These pretty much all just look like the usual legacy crypto horror show bugs.

Can you elaborate?

trying to parse ASN.1/X.509 in C is, to put it mildly: error prone

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

This seems relevant:

Future of Memory Safety Challenges and Recommendations 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. ... """

One type error, one timing attack and six memory safety problems. Defect ratio checks out.

Ratio 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)?

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

No 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"

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

[1] https://security.googleblog.com/2021/04/rust-in-android-plat...

OpenSSL is not a security product. It's a loss leader for a security company that sells support contracts. There isn't very much incentive for them to turn out a good product.

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

openSSL 1.1.1 is EOL 2023-09-11 which is likely to be the bigger problem for random-distro-XYZ

A reminder that LibreSSL exists and has a fraction of the problems OpenSSL does.

https://www.libressl.org/

Why isn't it used more?

It's not 100% compatible with existing applications. IIRC Alpine Linux tried to switch and reverted back to openssl twice.

Gentoo and OPNsense also switched back (to be precise, stopped supporting both and now just support OpenSSL) for the same reason.

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

Is your FIPS .dll/.so publicly available?

It's surprisingly hard to get FIPS crypto in Golang on Windows.

> A reminder that LibreSSL exists and has a fraction of the problems OpenSSL does.

Ahem. Cough.

Maybe I should leave this little link here for a patch published today ?

https://ftp.openbsd.org/pub/OpenBSD/patches/7.2/common/018_x...

Going by the patch, that looks like the same bug as OpenSSL fixed. That's seven of the eight bugs not applicable.

But this is just one round of patches, I have no further information or experience on/with LibreSSL or how the features compare. Just saying that one patch release does not mean either secure or insecure software.

Commit message: https://marc.info/?l=openbsd-cvs&m=167578479210650&w=2

> "Release date for this was set to be January 31. Unilaterally pushed back to February 7 by OpenSSL by way of announcement of many completely unrelated embargoed issues, some of which they had been sitting on since July 2020"

This exemplifies one of the key reasons OpenBSD forked OpenSSL. For those who haven't seen it I'd recommend this presentation from Bob Beck[1], around the 10 minute mark he recounts fixing issues in the memory allocator which had been reported 4 years prior. Seems there's still a similar backlog sitting behind embargoes?

[1] https://www.youtube.com/watch?v=GnBbhXBDmwU

A reminder that rustls exists, and leverages the Rust compiler to make sure no memory safety issues exist in your TLS implementation:

https://github.com/rustls/rustls

Some thoughts on lessons learned from other projects/vulnerabilities:

https://docs.rs/rustls/latest/rustls/manual/index.html

For cryptography it uses the ring-library which still relies on C-Code in many places. Additionally there is no API-stability (still v0.*) and the last official audit was 3 years ago.

The project has potential but isn't quite ready for prime time yet.

Importantly, that C code (and assembly) is in the guts of crypto primitives. Those tend to be a lot easier to test than higher level X.509 parsing code, which I think is all done in safe Rust.

But for sure, taking a dependency on RusTLS from C code isn't a "boring" choice, and I wouldn't pretend to be confident that that would all go smoothly for a big project.

Reply on news.ycombinator.com