Please help reviewing CVE entries

[Léo Le Bouter]

Hello!

I have been feeling considerable amount of stress reviewing CVE entries
alone, these days I want to focus on other things and I've been feeling
held back because I abandonned the CVE entries reviewing task without
anyone doing it when I'm not here.

Right now at time of sending this email, I've reviewed in-order up
until CVE-2021-26709 on the 
https://nvd.nist.gov/feeds/xml/cve/misc/nvd-rss.xml feed, I use the
'quiterss' package as an rss reader.

I need help, it's not necessarily a very hard task for most of it, but
it's one that requires you to be here often to read the feed.

Once I see a CVE entry, for example:

CVE-2021-30177  07.04.21 13:15
There is a SQL Injection vulnerability in PHP-Nuke 8.3.3 in the User
Registration section, leading to remote code execution. This occurs
because the U.S. state is not validated to be two letters, and the
OrderBy field is not validated to be one of LASTNAME, CITY, or STATE.

I look at the summary, here "PHP-Nuke" seems to be the software name, I
know that the PHP eco-system is not very advanced with GNU Guix
packaging so I suspect it might not be packaged since not a lot of PHP
packages exist.

I run these commands to find out:

$ guix search php-nuke
$ guix search php nuke

No results, then some times GNU Guix names packages with the name of
the upstream repo rather and sometimes that's different, so I look into
the URL for the CVE entry:

https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-30177

Section: References to Advisories, Solutions, and Tools

Often the upstream repo URL is there with a commit or some times an
issue URL where we can find the upstream repo URL, in this case there's
just a PoC link:

https://gist.github.com/stacksmasher007/41e946fc9a5a2f0b6950626cc9d43d47

So after that, to make sure, I do a last try with a web search for
'PHP-Nuke' here we can find the upstream repo:

https://bitbucket.org/phpnuke/phpnuke

Then:

$ guix search phpnuke

Still no results, so we are pretty confident this doesnt exist in GNU
Guix and we can go to the next entry.

Probably there's no need to be as rigorous and precise as this for
every CVE entry, apply your best gut to it.

Then if you find a GNU Guix package for a CVE entry, look at the
version, figure out from available information if that version is
vulnerable, if it's vulnerable and you are certain, open a bug by
sending an email to bug-guix@gnu.org similar to these for example: 
https://issues.guix.gnu.org/47422 - try to include in the bug how to
fix the issue, by saying which version fixes it, or link to individual
patches or commits that can be applied (and backported if necessary) to
fix the issue.

Then once you sent the email and got the bug id, send an email like
this to control@debbugs.gnu.org to add the 'security' tag:

tags 47422 + security
quit

Replace 47422 with the bug id you got.

If you are not certain the version is vulnerable, then you can use 'may
be vulnerable' in the title and include all the details you've got so
others can pick it up, or even yourself later, so no information is
forgotten, similar to this https://issues.guix.gnu.org/47509 ; We
really don't want to forget patching a CVE.

You can find examples of existing bugs tagged for security with:

https://issues.guix.gnu.org/search?query=tag%3Asecurity

Also opened bugs tagged for security (definitely help tackle those as
well):

https://issues.guix.gnu.org/search?query=tag%3Asecurity+is%3Aopen

My security bugs I opened you can also take example from:

https://issues.guix.gnu.org/search?query=tag%3Asecurity+submitter%3Alle-bout

Then as for patching the actual issue in the GNU Guix package set, you
must first find the amount of dependents that package has using 'guix
refresh -l pkg_name', if it's larger than 300 then you will need to
graft to fix the security issue, otherwise you can just update the
package.

For grafts, you either have to use ABI compatible replacements like in 
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=f4dc8ac6dfa036d98aa0990ae22268a9650899d0
 or you must apply/backport patches to the version currently packaged
in GNU Guix like in 
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=52c8d07a4f7033534a71ac7efeec21a65d35c125

If you feel like you will get things wrong when backporting some patch
because you don't know the language enough or else then ask for help
and people will help with backporting ASAP. If backporting is too hard
and nobody can do it but fixing that particular security issue is
important because of the severity, then we have to negotiate cutting
corners with the rest of the GNU Guix community, for example recently
syncthing package: https://issues.guix.gnu.org/47627 - upgrade was
blocked because unvendoring was difficult on newer versions, seeing a
CVE it can be considered acceptable to not unvendor and leave things
vendored and build as-is until we can unvendor/unbundle properly later.

If the package has less than 300 dependents then you can just upgrade
that package and submit a patch on the bug you opened earlier, if you
are a committer and that update patch is rather trivial and everything
builds and some of the dependents too then you can probably push as-is
without additional review to fix the security issue in GNU Guix ASAP.

You can try to use: './pre-inst-env guix refresh -u pkg_name' to
automagically update the package, then use the 'etc/committer.scm'
script to generate commits then amend them with specific security fixes
markings.

About commit messages, what I've been doing until now is:

If the update fixes a single CVE entry and I am certain of that, append
in the title before the last period:

[fixes CVE-2020-1234]

If the update fixes multiple CVE entries and I know the full list of 
such CVE entries, append in the title before the last period:

[security fixes]

Then in the commit message body just below the title:

Fixes CVE-2020-1234, CVE-2020-1235 and CVE-2020-1236.

If I am not certain I have the full list, I use:

Fixes at least CVE-2020-1234, CVE-2020-1235 and CVE-2020-1236.

If I don't know the list at all or it's too time-consuming to obtain
the list I don't specify it at all and only specify '[security fixes]'
in the commit message title.

See for examples:

https://git.savannah.gnu.org/cgit/guix.git/log/?qt=grep&q=security
https://git.savannah.gnu.org/cgit/guix.git/log/?qt=grep&q=CVE

Please help!

Thank you!

signature.asc
Description: This is a digitally signed message part