Re: Please help reviewing CVE entries

[Joshua Branson]

Léo Le Bouter <lle-bout@zaclys.net> writes:


This is a really good write up.  This could be documented in the
contributing section of the manual, to give newcomers an idea of how
they can help out!  I'll add it to my list of guix things to do, but I'm
pretty slow to do the things on that list.  Maybe someone will beat me
to it!

> 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!
>

-- 
Joshua Branson (joshuaBPMan in #guix)
Sent from Emacs and Gnus
  https://gnucode.me
  https://video.hardlimit.com/accounts/joshua_branson/video-channels
  https://propernaming.org
  "You can have whatever you want, as long as you help
enough other people get what they want." - Zig Ziglar