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!
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.
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...
> 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.
Even the best auditors I've seen have crappy software that will flag the Apache Version String even if they're also running on the machine and can identify that it's actually an up-to-date .deb running.
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.
To be fair, that was the intent of versioning. As an external auditor who is aware of backporting, it’s very difficult to track down and investigate if the version in use has been patched or not - I assume system owners have the same difficulty. If versioning doesn’t clearly articulate patch level, then it’s the patching protocols which are broken, not the auditor.
Distros have different goals from upstream software, and upstreams all have different policies too.
For instance, plenty of upstream software never even releases security fixes in older versions, yet distributions might be committed to supporting them for 5 or 10 years in their LTS releases.
The only universal solution to this is back-porting: it reduces the risk of exposing LTS release customers to backwards compatibility issues, but increases the risk of a bad patch slightly.
If upstreams cared about the things distro customers cared about too (don't break my stuff I haven't changed), it would be much easier to put the blame solely on distros, but they don't.
I do think it's unsolvable, since it's not a technical problem, but a societal one: Debian packages already list patched CVEs in their changelogs in a standardized format.
Introducing a new tool will only add another on top of the existing tools, when nothing tells us that people will use it! (plug the xkcd on n standards -> fix with a better standard -> n +1 standards)
Basically, you want to make everyone use a single tool when humans always strive to build something better or just different :)
The best we could hope to achieve is to have the CVE MITRE database start accepting "patched in" strings from all the distributors (so as Ubuntu pushes a signed and patched package to the archive, it pings the CVE db with a new version string for eg. Ubuntu-22.04 namespace).
Even that gets tricky with dependencies and issues covering multiple packages ("this is only patched if you've updated both of these"), though that's a technically solvable problem.
I agree with pretty much everything you said, but possibly a common metadata format (both our separate tools report differently but off the same data, etc).
I also think that you’re probably right we the patched in, it’s not infinitely scalable, but I doubt it needs to be anyway
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.
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 jammy-updates main restricted` to `/etc/apt/sources.list` to get the updated package
Does anyone know when Ubuntu might ship the fix?