Bug#1001451: Candidate script updates
Hi Neil,
On Tue, Jan 11, 2022 at 11:20:16AM +0000, Neil Williams wrote:
> Hi Salvatore,
>
> On Mon, 10 Jan 2022 17:10:15 +0100
> Salvatore Bonaccorso <carnil@debian.org> wrote:
>
> > > So for that epiphany tracker, there is a typo in the d.changelog -
> > > the automated link for CVE-2021-4508 is a 404.
> > >
> > > I've updated the script to catch this and report the error. From the
> > > security-tracker source-package page for epiphany, it looks like the
> > > d.changelog entry should be CVE-2021-45088 - a simple typo to omit
> > > the final repeated digit.
> > >
> > > Currently, I'm handling this by advising that the script is re-run
> > > using the offline support and a corrected list of CVE IDs.
> > >
> > > This also adds a --force-version option to the offline support, in
> > > case sid has moved ahead of the fixed version by the time the CVE
> > > list is updated.
> >
> > Ack, this works indeed in this case as the CVE-2021-4508 does not
> > exist (yet). But in other cases typos are e.g. just wapping a number
> > or misstype the year, or other typos, which lead to an existing CVE.
> > So basically this all really boils down to, people working on
> > security-tracker trying as much as possible, in the human limits :),
> > to do a diligent work as possible.
>
> The script also prints out the CVE description and then tries to
> identify any existing package link by checking the PackageAnnotation of
> each CVE. It prints a warning if the source package of the CVE from the
> changes input doesn't match the source package of the changes itself or
> the source package(s) of other CVEs in the list. It can't always be an
> error as the situation with embedded copies & removed|reintroduced
> packages makes it hard for the script. However, it should be obvious
> from the output if a typo has been made.
>
> I've also added output if a typo matches a CVE that is an NFU as
> there are lot more of those in data/CVE/list e.g.
>
> $ cat test.changes| ./bin/grab-cve-in-fix --input
> grab-cve-in-fix - INFO - Retrieving data STDIN ...
> grab-cve-in-fix - INFO - CVE-2021-45085: (XSS can occur in GNOME Web
> (aka Epiphany) before 40.4 and 41.x before ...)
> grab-cve-in-fix - INFO - CVE-2021-45086: (XSS can occur in GNOME Web
> (aka Epiphany) before 40.4 and 41.x before ...)
> grab-cve-in-fix - INFO - CVE-2021-45087: (XSS can occur in GNOME Web
> (aka Epiphany) before 40.4 and 41.x before ...)
> grab-cve-in-fix - INFO - CVE-2021-3757: (immer is vulnerable to
> Improperly Controlled Modification of Object Pr ...)
> grab-cve-in-fix - ERROR - CVE CVE-2021-3757 is not attributed to a
> Debian package: ['NOT-FOR-US', 'NOTE']
>
> (test.changes in this case was edited to change the typo to
> CVE-2021-3757 to demonstrate the output).
Thanks!
I noted another case which triggers an error but in this case should
not (I think the same issue might be present in merge-cve-list, but
need to double check):
../gragcvefix/bin/grab-cve-in-fix --tracker https://tracker.debian.org/news/1294112/accepted-systemd-2502-1-source-into-unstable/
grab-cve-in-fix - INFO - Retrieving data from distro-tracker...
grab-cve-in-fix - INFO - CVE-2021-3997:
grab-cve-in-fix - ERROR - CVE CVE-2021-3997 is not attributed to a Debian package: ['RESERVED']
(note I used your worktree teqnique to access the current versions,
thanks again for this tip). In the above case MITRE has not yet
populated the CVE entry and so the entry looks like:
CVE-2021-3997 [Uncontrolled recursion in systemd's systemd-tmpfiles]
RESERVED
- systemd <unfixed> (bug #1003467)
[bullseye] - systemd <no-dsa> (Minor issue; can be fixed via point release)
[buster] - systemd <ignored> (Minor issue; not exploitable before upstream commit e535840)
NOTE: https://bugzilla.redhat.com/show_bug.cgi?id=2024639
NOTE: https://github.com/systemd/systemd/pull/22070
NOTE: https://www.openwall.com/lists/oss-security/2022/01/10/2
NOTE: Exploitable after (but present before): https://github.com/systemd/systemd/commit/e5358401b5df8d395e99815b7a69b8424887472c (v242-rc1)
NOTE: Prerequisite/Preparation: https://github.com/systemd/systemd/commit/3bac86abfa1b1720180840ffb9d06b3d54841c11
NOTE: Prerequisite/Preparation: https://github.com/systemd/systemd/commit/84ced330020c0bae57bd4628f1f44eec91304e69
NOTE: Fixed by: https://github.com/systemd/systemd/commit/5b1cf7a9be37e20133c0208005274ce4a5b5c6a1
> I might need to brush up on my Perl and make a patch for lintian which
> downloads the sec tracker JSON and checks the CVE list in the .changes
> file - warnings from lintian are more likely to get fixed prior to
> upload. Depends if you think this happens sufficiently often that it is
> a problem worth solving. (Considering how long it's been since I did
> that amount of code in Perl, maybe I'm better filing the bug against
> lintian and seeing if someone else can come up with a patch... - again,
> only if it happens sufficiently often.)
I'm not sure. It probably does not warrant try to cover this in lintian.
>
> > But if you spot an easy or obvious to detect case which the script can
> > warn of, then this can be helpful! After all you are trying to write
> > up scripts which should help the workflow.
> >
> > > It's hard to see how to best test these scripts properly on an
> > > ongoing basis. The "correct" output of each script depends entirely
> > > on the current state of data/CVE/list and the setup_paths support
> > > gets in the way of using a static CVE list in a test directory.
> > >
> > > I yet may push all of the non-argparse code into a
> > > lib.python.sectracker module to at least have some way to test
> > > individual functions with carefully mangled static copies of
> > > data/CVE/list content.
> >
> > In general I would find it perfect if we can have a sort of testsuite
> > or CI for the code part indeed of the security-tracker. In fact the
> > situation now without any tests has potential for many breackages when
> > one want to fix something, as the code has grown over decades almost
> > :). If you have a solution for that, and if splittiong out code into
> > libs can help, then that would be a welcome improvmenet.
>
> OK, I had looked at the lib/python/sectracker_test directory but the
> tests failed after trying to find lenny apt sources & then failed again
> when I changed that to something current....
>
> I'll work on CI that can run in Salsa & hopefully will be easier to
> keep up to date.
Yes the test suite cannot work since some years now.
> > (Note: I expect that the security-tracker will need some refactoring
> > in the 2022 year, as MITRE will change e.g. how data is exported and
> > which formats are supported, in particular this will affect our
> > automatic update scripts currently relying on downloading the
> > allitmes.html file, where it's planned now that this will change and
> > there will be only a JSON export of the data, we will need to adapt
> > the security-tracker on that regard, and possibly you will be
> > interested here :))
> >
> > > For now, I'll mirror the real changes in data/CVE/list, trying to
> > > use the scripts to make some of the same changes. (Not all
> > > operations on data/CVE/list are to be covered.)
> > >
> > > Should bin/merge-cve-files also clean up the .xpck files that are
> > > created? On success only?
> >
> > Will be good to not have them lying around afterwards yes.
>
> I'll fix that.
Thanks.
A feature request which does not belong to this bug directly, but I'm going to
mention it nevertheles shortly here, hoping you are not getting too spammed
with ideas:
E.g. today there was a new round of mfsa's for firefox. It would be "handy" if
we can have merge-cve-list's accepting as well the list, while the CVEs are not
yet initially filled in in data/CVe/list. E.g. having yet the CVEs from
https://www.mozilla.org/en-US/security/advisories/mfsa2022-01
touched, have a local firefox.list containing
CVE-2022-22746 [optional temporary descripton]
- firefox <unfixed>
NOTE: https://www.mozilla.org/en-US/security/advisories/mfsa2022-01/#CVE-2022-22746
CVE-2022-22747
- firefox <unfixed>
NOTE: https://www.mozilla.org/en-US/security/advisories/mfsa2022-01/#CVE-2022-22747
[...]
and then merge-cve-list doing the population correctly.
but again maybe we are going to over-engeneer something. maybe let's just
postone the idea for later.
Salvatore
Reply to: