[HN Gopher] OpenSSL Security Advisory [7th February 2023]
___________________________________________________________________
OpenSSL Security Advisory [7th February 2023]
Author : FiloSottile
Score : 115 points
Date : 2023-02-07 16:45 UTC (6 hours ago)
(HTM) web link (www.openssl.org)
(TXT) w3m dump (www.openssl.org)
| LinuxBender wrote:
| 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
| irogers wrote:
| 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. ... """
| [deleted]
| some_furry wrote:
| 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.
| tptacek wrote:
| Why is that interesting?
| midasuni wrote:
| 2 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 wrote:
| It was never 2 years as it's not 1 year now. It's specified
| in days (397 currently, 825 and 1185 days before).
| tialaramex wrote:
| 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.
| nekoashide wrote:
| 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.
| tptacek wrote:
| 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.
| some_furry wrote:
| 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.
| [deleted]
| Rafuino wrote:
| Is taking 2 years to address a vulnerability normal?
| tptacek wrote:
| 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.
| some_furry wrote:
| > 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 wrote:
| 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. :)
| some_furry wrote:
| 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.)
| tptacek wrote:
| Everybody is!
| some_furry wrote:
| 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.)
| dottedmag wrote:
| 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.
| midasuni wrote:
| "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]
| kroeckx wrote:
| Yes, the dates are correct.
| KennyBlanken wrote:
| A reminder that LibreSSL exists and has a fraction of the
| problems OpenSSL does.
|
| https://www.libressl.org/
| colmmacc wrote:
| 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.
| mappu wrote:
| Is your FIPS .dll/.so publicly available?
|
| It's surprisingly hard to get FIPS crypto in Golang on
| Windows.
| [deleted]
| traceroute66 wrote:
| > 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...
| lucb1e wrote:
| 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.
| brynet wrote:
| 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"
| g0xA52A2A wrote:
| 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
| dochtman wrote:
| 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
| Flocular wrote:
| 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.
| flangola7 wrote:
| Why isn't it used more?
| wolf550e wrote:
| It's not 100% compatible with existing applications. IIRC
| Alpine Linux tried to switch and reverted back to openssl
| twice.
| Arnavion wrote:
| Gentoo and OPNsense also switched back (to be precise,
| stopped supporting both and now just support OpenSSL) for
| the same reason.
| Nimi wrote:
| 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...
| formerly_proven wrote:
| These pretty much all just look like the usual legacy crypto
| horror show bugs.
| l33t233372 wrote:
| Can you elaborate?
| blibble wrote:
| trying to parse ASN.1/X.509 in C is, to put it mildly: error
| prone
| stabbles wrote:
| 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.
| Flocular wrote:
| openSSL 1.1.1 is EOL 2023-09-11 which is likely to be the
| bigger problem for random-distro-XYZ
| [deleted]
| topspin wrote:
| One type error, one timing attack and six memory safety problems.
| Defect ratio checks out.
| akira2501 wrote:
| 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.
| lucb1e wrote:
| 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)?
| topspin wrote:
| 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.
| [deleted]
___________________________________________________________________
(page generated 2023-02-07 23:01 UTC)