4 ms·

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

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.
  - GauntletWizard 4y ago
    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.
- hsbauauvhabzb 4y ago
  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.
  - insanitybit 4y ago
    I'm in agreement. The distros really get in the way of things like this and it's kind of on them to address it.
    - necovek 4y ago
      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.
      - hsbauauvhabzb 4y ago
        I don’t think this is an unsolvable issue. Better naming conventions, or some kind of standardised util would do. $ patchinfo openssl 3.0.6 LTS Patches: Cve-2022-xxx Cve-2022-xxx Etc
        necovek 4y ago
        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.
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.

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.
- GauntletWizard 4y ago
  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.
hsbauauvhabzb 4y ago
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.
- insanitybit 4y ago
  I'm in agreement. The distros really get in the way of things like this and it's kind of on them to address it.
  - necovek 4y ago
    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.
    - hsbauauvhabzb 4y ago
      I don’t think this is an unsolvable issue. Better naming conventions, or some kind of standardised util would do. $ patchinfo openssl 3.0.6 LTS Patches: Cve-2022-xxx Cve-2022-xxx Etc
      - necovek 4y ago
        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.

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.