31

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.

Braiam
  • 67,791
  • 32
  • 179
  • 269
Lexible
  • 1,355
  • 4
  • 16
  • 31
  • Rest assured that the Ubuntu team is working on this, no matter what. – Artur Meinild Nov 01 '22 at 18:12
  • 1
    In the future, if you run apt policy <package-name>, you'll get info if there is an updated package. – Artur Meinild Nov 01 '22 at 18:22
  • 1
    @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. – Lexible Nov 01 '22 at 21:40
  • 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. – muru Nov 02 '22 at 04:45

1 Answers1

77

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!

user535733
  • 62,253
  • You beat me to it. The point is, a patch was just released, so openssl and libssl3 (on 22.04) can be updated. – Artur Meinild Nov 01 '22 at 18:17
  • 3
    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? – Phil Gyford Nov 01 '22 at 19:07
  • @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. – user535733 Nov 01 '22 at 19:32
  • 4
    Awesome in-depth writeup. Had no idea patches worked this way! – sheng Nov 01 '22 at 21:02
  • 9
    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. – Eric Twilegar Nov 01 '22 at 21:25
  • 1
    @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. – Florian Heigl Nov 03 '22 at 22:47
  • 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. – daparic Mar 21 '23 at 02:37