I am excited that Serokell, the NLNet Foundation through their Next Generation Internet Zero Discovery initiative (NGI0 Discovery), and I have partnered on the project of adding CVE reporting to nixpkgs-update. NGI0 Discovery is made possible with financial support from the European Commission.
We will be working on adding a report to each new update proposal that indicates if the update fixes (or introduces) security issues known to the Common Vulnerabilities and Exposures (CVE) system.
If you are also interested in supporting nixpkgs-update development and infrastructure, please consider contributing on Patreon.
Failed approach to add types to Nix raised $3k in few days, and working updater got $0…
It seems like people are willing to pay for empty promises than to something real.
I appreciate your support of and concern for nixpkgs-update! That Patreon page is new and wasn’t the main point of the post. It looks like only 10 people have clicked through to it so far. I don’t think this one link is close to comparable to the marketing done by the adding types project. In the future, I’ll do a dedicated fundraiser that I announce more broadly.
nixpkgs-update is awesome, keep up the good work!
I’m a backer now.
Wow, it has been a while since I posted an update about our progress on getting CVE reporting. Sorry about that!
@Lucus at Serokell has mostly finished making a program that downloads the National Vulnerability Database in a incremental way and loads it into a sqlite database for querying. He also worked on making it efficient to query if a version has CVEs associated with it, which is not trivial because CVEs can support multiple matching styles like exact matches and range matches.
Today, I made the basic CVE report that tries to match the Repology project name with the CVE project id, and I’m now running nixpkgs-update with this. Hopefully we’ll see some actual reports soon.
Here’s an example of how a report would have looked for a recently updated package that someone noticed had a CVE:
./result/bin/nixpkgs-update check-vulnerable bird 2.0.5 2.0.6
Experimental: CVE security report (click to expand)
CVEs resolved by this update:
CVEs introduced by this update:
CVEs present in both versions:
I’ve noticed that many of the CVE reports are obviously wrong, like the CVE report for
tor is reporting CVEs for
tor-browser. I’m noting wrong ones I find so we can go back and address them.
Which leads into the main issue left to address, which is the mapping of nixpkgs derivation/package to a Common Platform Enumeration (CPE). This is tricky to do automatically since different projects make use of different fields within the CPE. We will need to maintain a curated mapping from attrpaths to fix these issues. It would probably make sense to eventually incorporate this into the
meta derivation information once we find a stable format.
There are also issues to resolve around the ordering of versions. There are a lot of different ways that projects represent release candidates and some projects change versioning schemes as they go, both of which make it hard to see where a version falls within a CVE version range match.
Please let me know if you have any feedback on our work!
Will it make any attempt to recognize patching or will we get nagged to bump the version of packages we’ve dutifully backported fixes to in the stable branch?
Ris, I’ll answer that when I have more time.
The first report seems like it might be correct:
NIce to see someone working on this!
I’ve done some work on the matching front and I “suffered” from the same issues for https://broken.sh. If you feel like chatting about potential ways to fix/address/aid this kind of automatic matching hit me up on IRC (
andi- @ freenode).
Nice to see this!
Suggestion. Use color to highlight the importance of each CVE as well as the
Experimental: CVE security report (click to expand) line.
Maybe we could also let ofborg automatically add the security label in case a CVE is mentioned. What do you think @grahamc?
I do not have any immediate plans to recognize patches. Is there some standard patch format that is easy to tell addresses a CVE? It looks like some patches from Debian have the CVE number in the name.
nixpkgs-update does not consider the stable branch for anything it does, so it won’t be nagging about anything related to that.
It is possible that the report could note a CVE that was already patched, but I think a version update is a good time to look to see if the patches are still necessary.
It looks like color is not a trivial thing to add to github flavored markdown github - Is there a way to get colored text in GitHubflavored Markdown? - Stack Overflow
I definitely can add a word or two that would summarize the report before you expand it.
I was just thinking about this - would it be possible for there to be a special property in the
meta for declaring “no, really, it’s fixed for this”? Just a list of CVE ids at its simplest?
Guix is doing exactly that: https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/networking.scm#n2322
What vulnix currently does is inspect the
patches drv attribute and scan for CVE identifiers in patch names. Although not perfect, it works well in many cases.
Great - I knew naming my patches properly would come in useful.
…though I can imagine cases where this would be an insufficient mechanism - another source of false positives is vulnerability databases having inaccuracies in their “versions vulnerable” information. This would provide no way of providing this information without having to put in a dummy/null “fix”.
@ris It’s not that bad anyway. Of course, patch name detection is a heuristic. But at least with vulnix, each CVE is reported only once for each unique combination of (pname, version, release). Given the fact that new releases often ship updated package versions, the amount of false positives should be manageable.
I’m more concerned with false negatives…
Well, there are certainly times I’ve named a patch
CVE-1234-1234-partial.patch because it only patches e.g. some of the troublesome sites of a broader problem. See recent activity on
ghostscript for instance.
Yeah, that happens from time to time. We need to be careful not to close the associated Vulnerability Roundup ticket in this case.