List of affected ranges vs list of fixes?

Grype
1

Hi friends! I’m working on a Grype feature where users will be able to tell grype that they have Ubuntu Pro / ESM available, and Grype will suggest fixes that involve pro-only releases. Right now, some users are frustrated that, even if Ubuntu Pro is available, Grype will only suggest fixes from the non-pro dpkg repositories, so users might miss that they have an upgrade available. I’m excited to fix this. See also Store and suggest remediations besides package upgrades · Issue #2615 · anchore/grype · GitHub

The rest of this post is about some grype database internals about how this information can be written down.

For the rest of this post, we’re thinking about this Ubuntu CVE file which lists that ruby-rack has both ESM and non-ESM fixes for CVE-2022-44572. This situation occurred because there was an Ubuntu Pro only fix for this CVE in Jammy, but then upstream Debian pulled in a fix, and then that fix was pulled into Jammy even though it was past normal support window. So an Ubuntu Pro customers can install either the Pro/ESM only fix or the upstream fix. The web UI currently only shows the main repo fix, but someone might have built an image with the ESM only fix before the mainline fix was available, and we don’t want them to have an FP.

It seems like right now I have no way of writing down “either patch is good” in the AffectedRanges in the affected package blob. For example, with these ESM fixes, we have < 2.1.4-5ubuntu1+esm3 and < 2.1.4-5ubuntu1.1. We can get these two ranges in the DB no problem, but the issue is that because 2.1.4-5ubuntu1+esm3 is less than 2.1.4-5ubuntu1.1, fixes for one range result in FPs because it looks like they are affected. In other words, if a user has installed 2.1.4-5ubuntu1+esm3, grype will currently report it as vulnerable, and that they should install 2.1.4-5ubuntu1.1. Note that this is only true for packages that have both an ESM and non ESM fix, which is pretty rare, so one possibility is to live with it; we’re just recommending that people upgrade past the old pro-only fix. Maybe we should try to represent a “last affected version” that matches at <= 2.1.4-5ubuntu1 which will be false for both fixes? But that loses the information about what fixes are actually available. And it will be false for 2.1.4-5ubuntu1+esm1 which is vulnerable, so that’s no good.

What I’d really like to do is write down an APH with a list of patches, and if any patch seems to have been applied then the package is not vulnerable. Unless I am missing something, the DB can’t do that right now. What do you all think? In other words, I’d like to have some affected package handles that, instead of having a list of vulnerable ranges, have a list of fixed versions, and grype will report these APHs as vulnerable if no fix is applicable.

Let me know what you think.

1 Like
2

I think the way I envision these AvailableFixes arrays working:

  1. We either have AvailableFixes or AffectedRanges for a given affected package handle; I don’t think it makes sense to have both.
  2. Each entry in AvailableFixes has a qualifiers field similar to package qualifiers, but it lets the matcher in Grype decide whether the fix is applicable.
  3. If any AvailableFix appears to have been applied and is allowed by qualifiers, the APH is considered not vulnerable.
  4. For example, we could have a qualifier that means the fix is only available from Ubuntu Pro, and drop that for users that haven’t opted in to those fixes. We could also have a qualifier that means the fix is only available from RHEL EUS, and similarly drop that in scans where we don’t have RHEL EUS turned on.

I think this approach might strike a between the giant rewrite that treating advisory/patch announcement as its own DB entity would be, and trying to shoehorn these alternate fix sources into the current data model.

1 Like