Insecure imagemagick version in NixOS 20.09

Development Security
#1

I’ve run vulnix --system on my server which is on the 20.09 branch and it showed a LOT of open CVEs which is a bit concerning. The worst of them is imagemagick-6.9.11-60 with 81 open CVEs which go up to a score of 9.8 (and some of the CVE’s date back to 2016).
There is also security roundup 99 which detected 79 of these CVEs for imagemagick.

Now I’m wondering a bit how e.g. the CVE-2016-5841 is still apparently unresolved after over 4 years, plus I have some more questions :slight_smile: :

  • Are these CVEs mainly unpatched because of missing interest/manpower?
  • Vulnix has an entry about whitelisting in the readme. Is there already a whitelist of CVE’s for which an issue already exists? If so, can this list be made accessible?
  • Is there some kind of “policy/guideline” to decide which CVE’s should be patched and which not (of course as there is not enough manpower “as much as possible” is probably fine :grinning_face_with_smiling_eyes: )
  • Vulnix reported CVEs for 37 Packages built on my server and some of them aren’t in a security roundup. I could easily identify some of them as not applicable to NixOS (e.g. debian packaging problem), but wasn’t sure of others (e.g. NVD - CVE-2020-8625) which may need to be patched for NixOS 20.09. Should I just create Github issues for these and CC the Maintainers or is there a preferred way to handle them (e.g. so that they won’t appear in a following roundup)?
  • The package imagemagick currently doesn’t have any maintainer listed, but is obviously a dependency for lots of other packages. Is this a bad thing (and part of the problem) or are such prominent packages managed in a “more organically” way and therefore don’t need a maintainer?
2 Likes
#2

I think the problem is that the vulnerability database often contains bounds like every version up till and including 7.0.2 is vulnerable. Then even if the CVE is patched in the ImageMagick 6 branch and ImageMagick 6 is updated in nixpkgs, the package will still be detected as having the vulnerability due to the specified version bound.

If it is a maintained release (such as currently NixOS 20.09), every CVE should ideally be patched. Sometimes some CVEs do not get patched quickly. The reason is the same as why some PRs do not get reviewed quickly: there are too few people triaging them and making backport PRs.

Also, a lot of packages have maintainers that are inactive and do not take the responsibility to track CVEs and backport fixes. Finally, continuously triaging CVEs is relatively boring and repetitive work. IMO, we’d ideally pay someone several hours a week to do this work (from donations). I think this would go a long way of fixing CVEs in widely-used packages quickly.

I think this is currently one of the weak points in the NixOS server story. E.g. three weeks ago I updated and backported a remote remote execution vulnerability in MoinMoin that had been open for ~3 months. That really shouldn’t happen.

3 Likes
#3

It seems to me like the situation is not as bad as it seems to be, but it is messy nonetheless.

Firt of all it looks like that Vulnerability roundup 99: imagemagick-6.9.11-60: 79 advisories [9.8] · Issue #113454 · NixOS/nixpkgs · GitHub contains mostly false positives. I scanned through the first three CVEs and they were all backported ages ago. Apparently no one ever changed the version bounds in the CVE, nor even bothered to mention the CVE number in the commit message or the release notes. One of the core developers just seems to leave git commit message blank most of the time? Really makes one question the stability of the ecosystem…

Answering your other questions I know an answer to:

  • Are these CVEs mainly unpatched because of missing interest/manpower?

So yeah, more work by Nixpkgs contributors is always needed, but chances are
good that it is more a lack of good documentation on upstreams side in this
case than a need for more patching on our side. Still, looking on
upstreams practices, I don’t feel too motivated to spend much time to
dig through endless git logs, just because the authors didn’t bother to
reference things properly. That’s the kind of work I’d love to get paid
for, but doing this in my free time is too unnerving.

  • Is there some kind of “policy/guideline” to decide which CVE’s should be patched and which not (of course as there is not enough manpower “as much as possible” is probably fine :grinning_face_with_smiling_eyes: )

From what I can tell it’s only best effort atm. I’ve never seen a patch
for a CVE turned down in Nixpkgs though.

  • The package imagemagick currently doesn’t have any maintainer listed, but is obviously a dependency for lots of other packages. Is this a bad thing (and part of the problem) or are such prominent packages managed in a “more organically” way and therefore don’t need a maintainer?

Packages that are this central to the ecosystem should get a moderate
amount of attention anyway, but still it’s bad that there is no
maintainer at all. I could imagine listing myself as one and keeping an eye
on upstream releases.

5 Likes
#4

This is of course bad but unfortunately also to be expected. AFAIK even Debian has problems with this, e.g. Vulnerable source packages in the stable suite. Finding false positives, critical CVEs (the score isn’t always enough), etc. is unfortunately also a lot of work.

IMO that’s indeed a big part of the problem (especially with unmaintained packages / inactive maintainers). Currently there are 207 open issues (vs. 1750 closed ones, fortunately) that are labeled with the security tag: Issues · NixOS/nixpkgs · GitHub

Looks like those are here: nixos-vulnerability-roundup/whitelists at master · ckauhaus/nixos-vulnerability-roundup · GitHub

3 Likes
#5

Oh thanks a lot for your information and the link with the whitelists!

I’ve been going through the CVE’s for imagemagick and came to the same conclusion, the debian issue tracker actually helped me figure out the resolution to some issues.
As I already stated in the Github issue I’d really like to fix this problem “upstream” by being able to report a “fixed” backport version so that it’s not only “up to x.y” anymore. Seeing that debian and others (e.g. redhat) have the same issue I assume that it won’t work without an additional third party solution but I’ll see how the NVD responses (If I understand it properly this is where these version mappings are done, otherwise I’ll probably have to contact mitre).

1 Like