6 ms·

Ubuntu 22.04 ships with OpenSSL 3.0.2. Now that it's November 1, I was expecting to see `openssl` in a `sudo apt upgrade` but it is not there. Does anyone know

by nequo 4y ago

Ubuntu 22.04 ships with OpenSSL 3.0.2. Now that it's November 1, I was expecting to see `openssl` in a `sudo apt upgrade` but it is not there. Does anyone know when Ubuntu might ship the fix?

baggy_trough 4y ago
I would expect there should be a patch sometime today, but maybe not for a few hours based on prior experience.
_joel 4y ago
Also be aware sometimes fixes are backported, so the version isn't 100% accurate, ymmv etc.
- schlauerfox 4y ago
  Yes, it gets real confusing because they keep the major version the shipped with but usually add a letter or something to indicate the fix was backported to the older version without upgrading to a newer version number to prevent dependency issues. This got a heated debate on a project I was part of when a community member misunderstood this mechanism.
  - bityard 4y ago
    I _still_ have to go through this every time a clipboard warrior thinks they need to do a "security audit" in order to check a box for some meaningless certification or another. But of course THEY don't want to run the audit (sounds too much like work!) so they contract the audit out to a third-party that builds a database saying which versions of various software are vulnerable according to these CVEs. Of those, these contractors don't actually understand how Linux distributions are put together and their scanners _always_ flag fully patched and up-to-date machines as being vulnerable to X, Y, and Z. And then I have to explain that their scanners are broken by virtue of using a cheap-to-get value (the version number) as a totally inadequate proxy for something else (exposure to a vulnerability) when the two have only a weak to no actual correlation in real life. And then they shut up. Until the next audit comes around...
    - NovemberWhiskey 4y ago
      Literally having this discussion at work now. The vulnerability ticket against my service won't close until the vendor database is updated to reflect the security patch backport to Jammy, even though everyone agrees that 3.0.2-0ubuntu1.7 is not vulnerable. This is in any case notwithstanding the fact that the detection is in the base image of a Docker container from a vendor that confirms they don't use OpenSSL; and that said container runs in a context where the only TLS services it faces off to are run by AWS.
      - darkwater 4y ago
        A good definition of "security theater". I understand why the security team acts like that but it is still theater nonetheless.
    - throw0101a 4y ago
      > But of course THEY don't want to run the audit (sounds too much like work!) so they contract the audit out to a third-party that builds a database saying which versions of various software are vulnerable according to these CVEs. Of those, these contractors don't actually understand how Linux distributions are put together and their scanners _always_ flag fully patched and up-to-date machines as being vulnerable to X, Y, and Z. It depends on which software is used and how scans are done. For (e.g.) Nessus, if all it does a port/protocol scan, and something like "OpenSSL 3.0.2" is reported in the Apache/web server string, then it is going to get flagged. But you can set up "authenticated scans" where Nessus can go in as a (non-privileged) user and get a package listing. It then has a list of CVEs for each distro, which distro packages are vulnerable, and in which version the CVE was fixed in: you get a report saying "Package X is vulnerable because you are running Version a.b.c; please install Version a.b.c_foo1 to fix". Run a yum/apt-get update to pull in the newest package(s) and vulnerability is cleared on the next scan after the _foo1 patched package is running. The fact that your auditors (a) are using crappy scanning software, (b) do not know how to use it, and/or (c) the scanners cannot / are not allowed to login to get package versions, does not mean that auditing is inherently bad or useless.
      - 4y ago
  - depereo 4y ago
    VMware ship 1.0.2zb at the mo. I wouldn't want to maintain that fork!
    - vladak 4y ago
      One can buy premium support from OpenSSL for 1.0.x and let them supply patches and releases. This is what the company I work for does. At one point I was managing a fork of OpenSSL 0.9.7 for an OS version and in order to communicate what vulnerabilities were fixed, we appended the list of CVEs to the version string. The line grew to hideous dimensions as you can imagine.
- Shared404 4y ago
  You can find info at https://ubuntu.com/security/cves https://ubuntu.com/security/cves for *buntu.
NegativeK 4y ago
https://launchpad.net/ubuntu/+source/openssl/3.0.2-0ubuntu1.7 https://launchpad.net/ubuntu/+source/openssl/3.0.2-0ubuntu1.... is showing the patched version.
- nequo 4y ago
  After an `apt update` on jammy, `apt changelog openssl` still shows 3.0.2-0ubuntu1.6 for me as the latest from July 4. Do you know if there is something that is holding it back from trickling down? Edit (28 minutes later): I got the update now. Many thanks to Marc Deslauriers for his work!
TheHippo 4y ago
> Ubuntu packages are built with stack protector, reducing the impact of this CVE from remote code execution to a denial of service.
timvisee 4y ago
I just received the updated packages!
NicolaiS 4y ago
openssl packaged as `3.0.2-0ubuntu1.7` fixes the issue. So `>1, <= 3.0.2-0ubuntu1.6` is vulnerable. If you are using an APT mirror, you might not see the update yet. Consider adding `deb http://archive.ubuntu.com/ubuntu http://archive.ubuntu.com/ubuntu jammy-updates main restricted` to `/etc/apt/sources.list` to get the updated package

by nequo 4y ago

Ubuntu 22.04 ships with OpenSSL 3.0.2. Now that it's November 1, I was expecting to see `openssl` in a `sudo apt upgrade` but it is not there. Does anyone know when Ubuntu might ship the fix?

baggy_trough 4y ago

I would expect there should be a patch sometime today, but maybe not for a few hours based on prior experience.

_joel 4y ago

Also be aware sometimes fixes are backported, so the version isn't 100% accurate, ymmv etc.

schlauerfox 4y ago
Yes, it gets real confusing because they keep the major version the shipped with but usually add a letter or something to indicate the fix was backported to the older version without upgrading to a newer version number to prevent dependency issues. This got a heated debate on a project I was part of when a community member misunderstood this mechanism.
- bityard 4y ago
  I _still_ have to go through this every time a clipboard warrior thinks they need to do a "security audit" in order to check a box for some meaningless certification or another. But of course THEY don't want to run the audit (sounds too much like work!) so they contract the audit out to a third-party that builds a database saying which versions of various software are vulnerable according to these CVEs. Of those, these contractors don't actually understand how Linux distributions are put together and their scanners _always_ flag fully patched and up-to-date machines as being vulnerable to X, Y, and Z. And then I have to explain that their scanners are broken by virtue of using a cheap-to-get value (the version number) as a totally inadequate proxy for something else (exposure to a vulnerability) when the two have only a weak to no actual correlation in real life. And then they shut up. Until the next audit comes around...
  - NovemberWhiskey 4y ago
    Literally having this discussion at work now. The vulnerability ticket against my service won't close until the vendor database is updated to reflect the security patch backport to Jammy, even though everyone agrees that 3.0.2-0ubuntu1.7 is not vulnerable. This is in any case notwithstanding the fact that the detection is in the base image of a Docker container from a vendor that confirms they don't use OpenSSL; and that said container runs in a context where the only TLS services it faces off to are run by AWS.
    - darkwater 4y ago
      A good definition of "security theater". I understand why the security team acts like that but it is still theater nonetheless.
  - throw0101a 4y ago
    > But of course THEY don't want to run the audit (sounds too much like work!) so they contract the audit out to a third-party that builds a database saying which versions of various software are vulnerable according to these CVEs. Of those, these contractors don't actually understand how Linux distributions are put together and their scanners _always_ flag fully patched and up-to-date machines as being vulnerable to X, Y, and Z. It depends on which software is used and how scans are done. For (e.g.) Nessus, if all it does a port/protocol scan, and something like "OpenSSL 3.0.2" is reported in the Apache/web server string, then it is going to get flagged. But you can set up "authenticated scans" where Nessus can go in as a (non-privileged) user and get a package listing. It then has a list of CVEs for each distro, which distro packages are vulnerable, and in which version the CVE was fixed in: you get a report saying "Package X is vulnerable because you are running Version a.b.c; please install Version a.b.c_foo1 to fix". Run a yum/apt-get update to pull in the newest package(s) and vulnerability is cleared on the next scan after the _foo1 patched package is running. The fact that your auditors (a) are using crappy scanning software, (b) do not know how to use it, and/or (c) the scanners cannot / are not allowed to login to get package versions, does not mean that auditing is inherently bad or useless.
    - 4y ago
- depereo 4y ago
  VMware ship 1.0.2zb at the mo. I wouldn't want to maintain that fork!
  - vladak 4y ago
    One can buy premium support from OpenSSL for 1.0.x and let them supply patches and releases. This is what the company I work for does. At one point I was managing a fork of OpenSSL 0.9.7 for an OS version and in order to communicate what vulnerabilities were fixed, we appended the list of CVEs to the version string. The line grew to hideous dimensions as you can imagine.
Shared404 4y ago
You can find info at https://ubuntu.com/security/cves https://ubuntu.com/security/cves for *buntu.

NegativeK 4y ago

https://launchpad.net/ubuntu/+source/openssl/3.0.2-0ubuntu1.7 https://launchpad.net/ubuntu/+source/openssl/3.0.2-0ubuntu1.... is showing the patched version.

nequo 4y ago
After an `apt update` on jammy, `apt changelog openssl` still shows 3.0.2-0ubuntu1.6 for me as the latest from July 4. Do you know if there is something that is holding it back from trickling down? Edit (28 minutes later): I got the update now. Many thanks to Marc Deslauriers for his work!

TheHippo 4y ago

> Ubuntu packages are built with stack protector, reducing the impact of this CVE from remote code execution to a denial of service.

timvisee 4y ago

I just received the updated packages!

NicolaiS 4y ago

openssl packaged as `3.0.2-0ubuntu1.7` fixes the issue. So `>1, <= 3.0.2-0ubuntu1.6` is vulnerable. If you are using an APT mirror, you might not see the update yet. Consider adding `deb http://archive.ubuntu.com/ubuntu http://archive.ubuntu.com/ubuntu jammy-updates main restricted` to `/etc/apt/sources.list` to get the updated package