Re: Tracking related source packages (new tool)
Hi,
I went through the several discussions and attempts that happened over
the past few years: we have several similar problems, typically:
- tagging CVEs for renamed packages in Debian
- tagging CVEs for renamed packages in Debian LTS or ELTS
- tagging CVEs for related package sets (branched/versioned/forked)
- suggesting CVEs for packages with embedded code copies
- etc.
but each warrant a different workflow/actions, e.g.:
- reporting for human validation
- updating data/CVE/list
- adding entries to data/CVE-/list
I worked on a tool that is flexible enough for us to experiment with
these use cases (see examples below).
I pushed it to salsa at:
https://salsa.debian.org/beuc/security-tracker/-/tree/related-cves
https://salsa.debian.org/beuc/security-tracker/-/commit/4d915b2701822342db65f751efe6c64b797947dc
Your comments and testing would be appreciated.
I can submit a proper merge request if we decide that the current
direction is OK.
A couple notes about our previous exchanges:
- The tool decides between and by checking the
list of sid packages in data/packages/ (auto-refreshed)
- The tool cannot decide whether a missing entry is an oversight or a
conscious decision (e.g. php7.0 missing for a CVE that affects
php>7.3). As Salvatore noted, we currently do not clutter
data/CVE/list but this means this implicit "not-affected" triage is
not documented and hence the script cannot use it. This can be
mitigated by one-way relationships and/or a year-based threshold.
Here are a few use cases:
# Report CVE entries that may have been missed for old renamed packages in
Debian
$ bin/related-cves.py --transitions data/renamed-packages --report
# Also report CVE entries that may have been missed for newly branched packages
in Debian (e.g. the golang-1.xx set)
$ bin/related-cves.py --transitions data/renamed-packages --report --two-way
# Automatically add entries renamed packages in ELTS, in the extended CVE list
file, restricting to supported packages
# (can complement the script for automated entries)
$ bin/related-cves.py --transitions data/renamed-packages.elts --extcve
data/CVE-EXTENDED-LTS/list --extadv data/ELA/list \
--start-year 2019 \
$(awk '{print $1}' < ../extended-lts/packages-to-support)
# Check issues that might affect krfb and vino in Debian (due to embedding e.g.
libvncserver)
$ bin/related-cves.py --transitions data/embedded-code-copies --format
embedded-code-copies --report krfb vino
# Check issues that might affect php5 in ELTS (due to embedding various
libraries)
bin/related-cves.py --transitions data/embedded-code-copies --extadv
data/ELA/list --format embedded-code-copies --report php5
The 'renamed-packages' file look like:
# Renamed/branched/forked packages, probably affected by the same CVEs
# Format: old-package... < new-package...
allegro4.4 < allegro5
cfengine2 < cfengine3
fltk1.1 < fltk1.3
golang-1.7 golang-1.8 golang-1.11 golang-1.15 < golang-1.16 golang-1.17
...
Last, the current tool usage:
$ bin/related-cves.py --help
usage: related-cves.py [-h] [--report] [--transitions TRANSITIONS]
[--format FORMAT] [--two-way] [--extcve EXTCVE]
[--extadv EXTADV] [--exttransitions EXTTRANSITIONS]
[--start-year START_YEAR]
[package [package ...]]
positional arguments:
package restrict action to these packages (default: all)
optional arguments:
-h, --helpshow this help message and exit
--report output related CVEs, grouped by package (default:
modify CVE list file)
--transitions TRANSITIONS
package transitions file (default: data/renamed-
packages)
--format FORMAT transitions file format (renamed-packages or embedded-
code-copies)
--two-way add missing CVEs to both sides of package transitions
(default: one-way)
--extcve EXTCVE extended CVE file to load, also becomes changes target
(e.g. data/CVE-/list)
--extadv EXTADV extended advisory file (e.g. data/XXX/list)
--exttransitions EXTTRANSITIONS
additional package transitions file (default: none)
--start-year START_YEAR
ignore CVEs prior to that date, e.g. the start of an
extended support release (default: 0)
What do you think?
Cheers!
Sylvain
On Fri, Feb 26, 2021 at 06:32:00AM +0100, Salvatore Bonaccorso wrote:
> Hi Moritz,
>
> Thanks for CC'ing.
>
> On Thu, Feb 25, 2021 at 08:01:42PM +0100, Moritz Mühlenhoff wrote:
> > Am Thu, Feb 25, 2021 at 05:30:05PM +0100 schrieb Sylvain Beucler:
> > > - This problem is similar/related to tracking embedded code copies.
> > > See https://salsa.debian.org/lts-team/lts-extra-tasks/-/issues/2
> > > With one difference: there's no reference source package.
> >
[SECURITY] [DLA 2749-1] gthumb security update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 - - Debian LTS Advisory DLA-2749-1debian-...@lists.debian.org https://www.debian.org/lts/security/Thorsten Alteholz August 29, 2021 https://wiki.debian.org/LTS - - Package: gthumb Version: 3:3.4.4.1-5+deb9u2 CVE ID : CVE-2019-20326 An issue has been found in gthumb, an image viewer and browser. A heap-based buffer overflow in _cairo_image_surface_create_from_jpeg() in extensions/cairo_io/cairo-image-surface-jpeg.c allows attackers to cause a crash and potentially execute arbitrary code via a crafted JPEG file. For Debian 9 stretch, this problem has been fixed in version 3:3.4.4.1-5+deb9u2. We recommend that you upgrade your gthumb packages. For the detailed security status of gthumb please refer to its security tracker page at: https://security-tracker.debian.org/tracker/gthumb Further information about Debian LTS security advisories, how to apply these updates to your system and frequently asked questions can be found at: https://wiki.debian.org/LTS -BEGIN PGP SIGNATURE- iQKTBAEBCgB9FiEEYgH7/9u94Hgi6ruWlvysDTh7WEcFAmEqyrBfFIAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDYy MDFGQkZGREJCREUwNzgyMkVBQkI5Njk2RkNBQzBEMzg3QjU4NDcACgkQlvysDTh7 WEdDEhAAomWHxaKyPJ/RPlnX9fQbMMYS+buWO4LIV+rb2UBLH3pCGQ24+mIMsg1L 19YPwnzTUzdmHg7WxTOW7aZt3/GdskspkLvfgAbb2pMsU+qRzuQBkCRJxf7Z2AKi D9B80nAAMIuxLyaurKiWkl7gfkEzIpQrGj3C+SlPstSTtewYM3OB22jB1oWkx/rz Dw4STwRgm3ci2wagesoT58p22YIbYMWzHvDN7sR9KIPL6h8MHK9YFPBN3t04b5iv Rti7ClLEPSsrMZhm+904dcMOXCsFC8KIKKPH+Mv/zcsUscnzPr/r1q7lN53nj6rb b/h92neaI5r6fZ6qNT/0yx8hJgIQvqYlRCRZSYhjVHSvIxcndmfgrtZO3RDx2a4A WIBxYJR2b7bsMCZIqBVMssezIISv3hfTf/g1MlWz56J4Mxezty4ly6f8ElBkeGy5 DcvLhbRw4/uvkzHK4GH2xQUFw1WI1royc/yhk240y2k5R4FMrXDVoXxQVcCmAVuY jNDOD+qDxOjRX+7eBsvcbkTXMp/kRgCY3oisrK4VeHIF2Jq3u28DOWCyCtS19I6T C+qU1qsTaRaw2pPUS6lbSWlllipb6WZoj0RJKD9fUTNtI7bkun3/1/86AsqbDcKc Q5EJo4NZa01aWJEHGKiRY+1ZAQbHz1+12hAywU0SgXuEOrkLRVE= =djd/ -END PGP SIGNATURE-
Accepted gthumb 3:3.4.4.1-5+deb9u2 (source all amd64) into oldoldstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Thu, 26 Aug 2021 21:03:02 +0200 Source: gthumb Binary: gthumb gthumb-data gthumb-dev Architecture: source all amd64 Version: 3:3.4.4.1-5+deb9u2 Distribution: stretch-security Urgency: medium Maintainer: Herbert Parentes Fortes Neto Changed-By: Thorsten Alteholz Description: gthumb - image viewer and browser gthumb-data - image viewer and browser - arch-independent files gthumb-dev - image viewer and browser - development files Changes: gthumb (3:3.4.4.1-5+deb9u2) stretch-security; urgency=medium . * Non-maintainer upload by the LTS Team. * CVE-2019-20326 A heap-based buffer overflow in _cairo_image_surface_create_from_jpeg() in extensions/cairo_io/cairo-image-surface-jpeg.c allows attackers to cause a crash and potentially execute arbitrary code via a crafted JPEG file. * additional fix in case orientation swaps width and height Checksums-Sha1: e4a7bf1e02ff31e8b39153d74205c91ce1558934 2824 gthumb_3.4.4.1-5+deb9u2.dsc add30eb9782a2476c5ec6357bc5d63dc34d5214c 3420356 gthumb_3.4.4.1.orig.tar.xz 98718ef721cc9d12384c73c88facdf8100d7b783 33360 gthumb_3.4.4.1-5+deb9u2.debian.tar.xz 8914161f9f0f8bafb15ed7278e7018c498be1400 1759656 gthumb-data_3.4.4.1-5+deb9u2_all.deb e7f2b4409ec3a234054e7435cb031864203eeb5a 4041108 gthumb-dbgsym_3.4.4.1-5+deb9u2_amd64.deb 70156e42c1857386acc9ca7febeb3bf1482532a5 608696 gthumb-dev_3.4.4.1-5+deb9u2_amd64.deb 44a52f4cd6abea4720cf19d51c5997b390e6c19d 21540 gthumb_3.4.4.1-5+deb9u2_amd64.buildinfo 475a0a0e3ff1b92acb64632d10cb832f5184b4b5 886802 gthumb_3.4.4.1-5+deb9u2_amd64.deb Checksums-Sha256: 1fe15a59f2a79082d35874f67e0507c880ffee16946cc844bfd11820e23ca0ec 2824 gthumb_3.4.4.1-5+deb9u2.dsc 4dc63bb1cc1f139259bba7f9fd1735182f16ba37254119a9f9c3e13a898a9533 3420356 gthumb_3.4.4.1.orig.tar.xz 60ec1d79ce28aa67f05102085534c4fb2c5553768b7ab9e51bff357c2fa4d25d 33360 gthumb_3.4.4.1-5+deb9u2.debian.tar.xz b90573d4c54dcdf27f50c930ff5f266d1647e5b96ba6a4f3d1bb4f4693cf288d 1759656 gthumb-data_3.4.4.1-5+deb9u2_all.deb 79181ba20bf0544d6208271b0603c7226e7e35115108f21d92f3b5bf8c0369d2 4041108 gthumb-dbgsym_3.4.4.1-5+deb9u2_amd64.deb 0f5e1c8c0a8844d568370bd6af127aa85e7f72ce3d9629697522449421de3dc5 608696 gthumb-dev_3.4.4.1-5+deb9u2_amd64.deb 4b2be98d26261373d812d2693b12a8006d74a3a56d00e7d35cb764dd6ae9f7b1 21540 gthumb_3.4.4.1-5+deb9u2_amd64.buildinfo f2edb180404880a97cbc4f544312f4191602f3a67a1d8da3db3dfe718f308f3c 886802 gthumb_3.4.4.1-5+deb9u2_amd64.deb Files: 6d91e1c90534835ed088a3df664a6fa3 2824 gnome optional gthumb_3.4.4.1-5+deb9u2.dsc 1745a756007f2a905c341131ae7d89f9 3420356 gnome optional gthumb_3.4.4.1.orig.tar.xz 2ab809786a8a3da9b1e6041b68b4d4cd 33360 gnome optional gthumb_3.4.4.1-5+deb9u2.debian.tar.xz 60985b09d7b43fc4aa067f471d49f466 1759656 gnome optional gthumb-data_3.4.4.1-5+deb9u2_all.deb a6aa7806f1981b9745dbb5bf564ee8ac 4041108 debug extra gthumb-dbgsym_3.4.4.1-5+deb9u2_amd64.deb 54a2d37abf7952d9012f83cb2decbf91 608696 devel optional gthumb-dev_3.4.4.1-5+deb9u2_amd64.deb 3e6d7d97bde55b206cad6b5ceff41539 21540 gnome optional gthumb_3.4.4.1-5+deb9u2_amd64.buildinfo b5e9fadd5d3b0c133074279e0065a6b6 886802 gnome optional gthumb_3.4.4.1-5+deb9u2_amd64.deb -BEGIN PGP SIGNATURE- iQKnBAEBCgCRFiEEYgH7/9u94Hgi6ruWlvysDTh7WEcFAmEqvJxfFIAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDYy MDFGQkZGREJCREUwNzgyMkVBQkI5Njk2RkNBQzBEMzg3QjU4NDcTHGRlYmlhbkBh bHRlaG9sei5kZQAKCRCW/KwNOHtYR5QnD/9Je2Qb9a374+fzkNIMMUeinJ2IbPzs WbjpbuulbPBToH9/Kbh0+w6TpfGt/vETCI4i2MXg0kzH/PLbNzN2EqVHoqh9mUXz Z9hWTTZmZ2Uc2pI6toJpm+rstHfkj1Pu9y7sRZpV22WNb6i4/nTwouZT0RdZO20p P5ZUOqIec/ztvPF+1o6fvKlkrI9kYx1UJuz5yviae13gGIkmhIOw9c088De+RMeZ 3cBQi0OXl9QE7NXWYA6FAbv5bZxOcw44mInNxDZhVksQufEH4bzto7UhP4czymD3 xkLqwCEuXq/TsledufqkJkYBSKMh5tVebPiZO6Rs7FTk4SL5jsqxNin5TMG6mecS /kV02++3eRiUIMqYcatzlhqDu3SNOhlf/XxP0cLnK5cxD3c3JQh1nM/qS2xMenZN WR0XR3CaYomG29VyG+14t/dC93Mm3Xxnzyqi6mP+uZYDXfmzZfcBWz6r2oz+yoaw /1fzSDCuVaWh9HK3VRFGcclCQOWs/l8CbpdEOkM+GgCsTCJTDMc94RqTZL+cjoCu /5fAjqOUog/+v1m+h64D3mIcazeU3b5N/0pt5dUpa54P2GKfdfkvnoRg+ddf9tzC c07l0KRBC+wfO9rD+FN0U+95jscuUFlmesNiHd3XlWaaY02xrI+f1EGo/RtWPIfJ U7StP8YFsvZG3A== =j7X+ -END PGP SIGNATURE-
Re: Tracking related source packages (new tool)
Hi Sylvain,
I have spent some time looking over your code and trying out the tool.
Overall, the code looks good, easy to understand, and useful in
functionality.
On Sat, Aug 28, 2021 at 08:30:56PM +0200, Sylvain Beucler wrote:
>
> Here are a few use cases:
>
> # Report CVE entries that may have been missed for old renamed packages in
> Debian
> $ bin/related-cves.py --transitions data/renamed-packages --report
>
This seems to produce useful output. I looked at some of the reported
findings for lua5.3 and it seems like the CVEs either apply, or or are
close enough that it would make sense to explicitly mark them
.
> # Also report CVE entries that may have been missed for newly branched
> packages in Debian (e.g. the golang-1.xx set)
> $ bin/related-cves.py --transitions data/renamed-packages --report --two-way
>
This produced much more output, much of which I am not sure would be
especially useful. Perhaps the security team, dealing with oldstable
through unstable might benefit from it, though. The year threshold you
mentioned seems to be useful here, if I understand it correctly.
> # Automatically add entries renamed packages in ELTS, in the extended CVE
> list file, restricting to supported packages
> # (can complement the script for automated entries)
> $ bin/related-cves.py --transitions data/renamed-packages.elts --extcve
> data/CVE-EXTENDED-LTS/list --extadv data/ELA/list \
> --start-year 2019 \
> $(awk '{print $1}' < ../extended-lts/packages-to-support)
>
> # Check issues that might affect krfb and vino in Debian (due to embedding
> e.g. libvncserver)
> $ bin/related-cves.py --transitions data/embedded-code-copies --format
> embedded-code-copies --report krfb vino
>
> # Check issues that might affect php5 in ELTS (due to embedding various
> libraries)
> bin/related-cves.py --transitions data/embedded-code-copies --extadv
> data/ELA/list --format embedded-code-copies --report php5
>
>
It appears that if the data/CVE/list split is implemented that this
would be another tool that requires updating to deal with the new
architecture. I wonder if it makes sense to proceed with implementing a
"list of filenames" that the script operates upon for each parameter
(e.g., CVE, DSA, DLA, etc.) in order to be ready for the coming change.
Regards,
-Roberto
--
Roberto C. Sánchez
