Score:31

How to install openssl 3.0.7 on Ubuntu 22.04?

tn flag

There's a highest severity security hole in openssl v3.0.x where x<7. The patched version (3.0.7) has officially dropped on November 1, 2022.

How to install/update openssl 3.0.7 on an Ubuntu 22.04 system?

Update: The vulnerability has been downgraded from Critical to High.

Artur Meinild avatar
vn flag
Rest assured that the Ubuntu team is working on this, no matter what.
Artur Meinild avatar
vn flag
In the future, if you run `apt policy <package-name>`, you'll get info if there is an updated package.
Lexible avatar
tn flag
@ArturMeinild Yes I know, and I did: the absence of a 3.0.7 for one of the foundational components of server security prompted my question.
muru avatar
us flag
Every few months/weeks/days, some component gets a vulnerability, but it's not going to be get updated to whatever version number that vulnerability scanners look for. ^That is how you check for whether your system is vulnerable to a given CVE and whether an update exists from Canonical for patching it.
Score:73
cn flag

First, you need to know that there are TWO ways to fix a vulnerability: Upgrading and Patching.

  • Upstreams emphasize "upgrade" in their public announcements simply because most folks don't know how to patch. But both methods are long-accepted practices.
  • Ubuntu (and many other distros) prefer to patch because upgrading can introduce new bugs and regressions. Upstreams usually make patches available specifically for this purpose.

This means that a fully-secure openssl package in Ubuntu WON'T be version 3.0.7. That's why we need to know the specific CVE(s) for the vulnerabilities.


Second, lets find those CVE(s). A bit of search-engine-fu reveals that the OpenSSL 3.0.7 release targets two CVEs:

  • CVE-2022-3602
  • CVE-2022-3786

Third, let's look at CVE-2022-3602 in the Ubuntu CVE Tracker:

Ubuntu CVE Tracker for CVE 2022-3786

This tells us a couple of important things:

  1. The Ubuntu Security Team is already tracking the issue.
  2. The only package affected is openssl.
  3. A patched package has already been released.

Fourth, let's dig a little deeper by looking at package details the tracker:

enter image description here

Now we know the exact version numbers of openssl packages that are patched and secure.

  • Reminder: It's patched, so the version number is NOT 3.0.7. But it's still secure; that CVE has been mitigated.

Finally, let's see if our 22.04 system has that secure package version

$ apt list openssl
Listing... Done
openssl/jammy-updates,jammy-security,now 3.0.2-0ubuntu1.6 amd64 [installed,automatic]

It's not the secure version (recall that the secure version is 3.0.2-0ubuntu1.7). But it was released today, so a simple sudo apt update and sudo apt upgrade shows an openssl update, then:

$ apt list openssl
Listing... Done
openssl/jammy-security,now 3.0.2-0ubuntu1.7 amd64 [installed,automatic]

SECURE! This system is now running a package that has been patched by the Ubuntu Security Team to mitigate CVE-2022-3602.

Checking if CVE-2022-3786 is also mitigated is left as an exercise for the student.


One final note: If a lot of this information was new to you (patching, CVEs, tracker, confusing version numbers), then one easy way to pierce the veil and understand what's going on is a couple episodes of the Ubuntu Security Podcast, a short weekly discussion of security-related topics from the Ubuntu Security Team. They want you to understand it!

Artur Meinild avatar
vn flag
You beat me to it. The point is, a patch was just released, so `openssl` and `libssl3` (on 22.04) can be updated.
Phil Gyford avatar
im flag
Great answer, but on my Ubuntu 22.04.1, when I do `sudo apt update` and `sudo apt upgrade` I don't see any openssl updates, and still see `3.0.2-0ubuntu1.6`. Am I missing a step?
user535733 avatar
cn flag
@PhilGyford check your output: For 22.04 `jammy-security` must be one of your sources. For more in-depth troubleshooting, please open a new question.
Sheng Slogar avatar
ec flag
Awesome in-depth writeup. Had no idea patches worked this way!
Eric Twilegar avatar
sk flag
The biggest issue with this approach is when trying to audit/verify that things like nginx or python are using the standard library and didn't do a static link. for instance in python you can do an `import ssl; ssl.OPENSSL_VERSION` which spits out `3.0.2 Mar 2022` and doesn't care about the ubuntu1.7 label. `lsof -p xxxx` on a python pid that has imported ssl should show the path to the .so which is usually `/usr/lib/x86_64-linux-gnu/libssl.so.3` and has a Oct 27 12:06 timestamp. nginx can be done by a `ldd $(which nginx)` and you can see it is using the correct .so file.
in flag
@EricTwilegar even if they arent statically linked, they need to be restarted - your lsof / ldd method is rather useful for that. traversing /proc/pid/fd also can be a helpful addon. all of that is useful, or even neccessary for envs where things need to be tight and controlled and you want to be able to make reliable statements, at least. ubuntu makes for a tricky territory in secure operations (i.e. to less good quality of openscap input data) and can be better to rely on an independent toolset for monitoring security updates.
eigenfield avatar
us flag
Thank you @EricTwilegar for your very important comment. It is ALWAYS better to know explicitly which parts are secured and other parts that are not secured.
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.