Please help reviewing CVE entries

Please help reviewing CVE entries

[Léo Le Bouter]

[-- Attachment #1: Type: text/plain, Size: 6562 bytes --]

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!

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Please help reviewing CVE entries

[Nicolò Balzarotti]

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

> Hello!

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

Thanks for your work
>
> 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 just subscribed to the feed, and noticed our version of dnsmasq might
be vulnerable to CVE-2021-3448, I'll follow your suggestions here and
open a bug report.

Thanks, Nicolò

Re: Please help reviewing CVE entries

[Léo Le Bouter]

[-- Attachment #1: Type: text/plain, Size: 969 bytes --]

On Fri, 2021-04-09 at 15:25 +0200, Nicolò Balzarotti wrote:
> Léo Le Bouter <lle-bout@zaclys.net> writes:
> 
> > Hello!
> 
> Hi!
> > 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.
> 
> Thanks for your work
> > 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 just subscribed to the feed, and noticed our version of dnsmasq
> might
> be vulnerable to CVE-2021-3448, I'll follow your suggestions here and
> open a bug report.
> 
> Thanks, Nicolò

That's one really good review you opened at bug#47674

Thank you so much!!

Keep it up!


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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