Re: Interpreting debsecan output

[Andy Smith]

Hello,

On Fri, Nov 04, 2022 at 01:06:02PM -0400, The Wanderer wrote:
> More relevantly to this thread, the equivalent check with 'apt-cache
> showsrc grub2' (since grub2 is the source-package name for the packages
> named in the CVE mentioned by debsecan, according to the OP) shows 49
> binary packages - no, that's not a typo, one short of fifty. Most of
> them follow the pattern of [name], [name]-bin, and [name]-dbg, but there
> are some outliers.
> 
> If any of those are installed (or possibly even just not purged?) on the
> machine in question, that might explain why debsecan shows the CVE as
> being applicable.

Good idea. Unfortunately that doesn't seem to be what's going on:

(All of the packages named start with "grub")

$ dpkg-query -l 'grub*'
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name VersionArchitecture Description
+++--==--=
un  grub (no description available)
un  grub-cloud-amd64 (no description available)
ii  grub-common  2.06-3~deb11u2 i386 GRand Unified Bootloader 
(common files)
un  grub-coreboot(no description available)
un  grub-doc (no description available)
un  grub-efi (no description available)
un  grub-efi-amd64   (no description available)
un  grub-efi-arm (no description available)
un  grub-efi-arm64   (no description available)
un  grub-efi-ia32(no description available)
un  grub-efi-ia64(no description available)
un  grub-emu (no description available)
un  grub-ieee1275(no description available)
un  grub-legacy  (no description available)
un  grub-legacy-doc  (no description available)
un  grub-linuxbios   (no description available)
ii  grub-pc  2.06-3~deb11u2 i386 GRand Unified Bootloader, 
version 2 (PC/BIOS version)
ii  grub-pc-bin  2.06-3~deb11u2 i386 GRand Unified Bootloader, 
version 2 (PC/BIOS modules)
un  grub-uboot   (no description available)
un  grub-xen (no description available)
un  grub-yeeloong(no description available)
un  grub2(no description available)
ii  grub2-common 2.06-3~deb11u2 i386 GRand Unified Bootloader 
(common files for version 2)

Maybe I need to file a bug on debsecan just so someone can tell me what
I am missing. 

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

Re: Interpreting debsecan output

[The Wanderer]

On 2022-11-04 at 13:08, Curt wrote:

> On 2022-11-04,   wrote:
> 
>> On Fri, Nov 04, 2022 at 02:52:29PM -, Curt wrote:

>>> I don't really know, but maybe because
> 
>>> Much like the official Debian security advisories, debsecan's 
>>> vulnerability tracking is mostly based on source packages. This
>>> can be confusing because tools like dpkg only display binary
>>> package names. Therefore, debsecan displays the more familiar
>>> binary package names. This has the unfortunate effect that all
>>> binary packages (including packages containing only
>>> documentation, for example) are flagged as vulnerable, and not
>>> only those packages which actually contain the vulnerable code.
> 
>>> I don't even understand that paragraph! Sorry for the
>>> interruption!
>> 
>> One source package may give birth to several binary packages. 
>> Typically you have at least three .deb -- the "business end" 
>> containing the binary (or library, or whatever), the -doc (which is
>> typically packaged separately to the benefit of those with tight
>> space requirements [1], and the -dev, with all the relevant headers
>> for when you want to compile things against this package.
> 
> So the man page means *all* the binary packages derived from a source
> package with a vulnerability are tagged, though some of those binary
> packages may have been patched for the vulnerability by the specific
> distro (or something).

Or some of them may even have never contained the vulnerable code in
question.

For example, look at FFmpeg. It builds a separate binary package for
each of several libraries, such as libavcodec and libavutil (and their
matching -dev packages), as well as for the executable tool ffmpeg
itself. All of these come from the single 'ffmpeg' source package.

Some of the source code in that package is shared between the various
libraries and other tools that are built from the FFmpeg project, but
some of it is used only by a single library or tool.

Now hypothesize that someone finds a security vulnerability in a part of
the FFmpeg source code that's used only by libavcodec, and a CVE is
filed against libavcodec as a result. Given the behavior described
above, this would result in debsecan showing the CVE for all of the
binary packages that are built from the ffmpeg source package, even
though only some of them - libavcodec[*] and libavcodec-dev, and
possibly ffmpeg itself - include the vulnerable code.

(The [*] represents the "SO version" of the library, which changes when
the library ABI changes, and so will not be the same for everyone who
reads this message.)

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: Interpreting debsecan output

[Curt]

On 2022-11-04,   wrote:
>
> On Fri, Nov 04, 2022 at 02:52:29PM -, Curt wrote:
>> On 2022-11-02, Andy Smith  wrote:
>> >
>> > So why is debsecan reporting this as a security issue?
>> >
>> > This is a very old host that has been continually upgraded since Debian

>> I don't really know, but maybe because

>>  Much like the official Debian security advisories, debsecan's
>>  vulnerability tracking is mostly based on source packages. This can be
>>  confusing because tools like dpkg only display binary package names.
>>  Therefore, debsecan displays the more familiar binary package names.
>>  This has the unfortunate effect that all binary packages (including
>>  packages containing only documentation, for example) are flagged as
>>  vulnerable, and not only those packages which actually contain the
>>  vulnerable code.

>> I don't even understand that paragraph! Sorry for the interruption!
>
> One source package may give birth to several binary packages.
> Typically you have at least three .deb -- the "business end"
> containing the binary (or library, or whatever), the -doc
> (which is typically packaged separately to the benefit of those
> with tight space requirements [1], and the -dev, with all the
> relevant headers for when you want to compile things against
> this package.
>

So the man page means *all* the binary packages derived from a source package 
with a
vulnerability are tagged, though some of those binary packages may
have been patched for the vulnerability by the specific distro (or
something).


-- 

Re: Interpreting debsecan output

[The Wanderer]

On 2022-11-04 at 12:49, to...@tuxteam.de wrote:

> On Fri, Nov 04, 2022 at 02:52:29PM -, Curt wrote:
> 
>> On 2022-11-02, Andy Smith  wrote:
>> 
>>> 
>>> So why is debsecan reporting this as a security issue?
>>> 
>>> This is a very old host that has been continually upgraded since
>>> Debian
>> 
>> I don't really know, but maybe because
>> 
>> Much like the official Debian security advisories, debsecan's 
>> vulnerability tracking is mostly based on source packages. This can
>> be confusing because tools like dpkg only display binary package
>> names. Therefore, debsecan displays the more familiar binary
>> package names. This has the unfortunate effect that all binary
>> packages (including packages containing only documentation, for
>> example) are flagged as vulnerable, and not only those packages
>> which actually contain the vulnerable code.
>> 
>> I don't even understand that paragraph! Sorry for the
>> interruption!
> 
> One source package may give birth to several binary packages. 
> Typically you have at least three .deb -- the "business end" 
> containing the binary (or library, or whatever), the -doc (which is
> typically packaged separately to the benefit of those with tight
> space requirements [1], and the -dev, with all the relevant headers
> for when you want to compile things against this package.
> 
> Sometimes you have a client/server package (think, e.g. PostgreSQL), 
> where you want to be able to install clients and servers separately.
> 
> Sometimes you have one source package which can produce different 
> flavours of binary (think Emacs: -nox for no GUI, GTK, Lucid, etc.
> for different GUI widget sets).
> 
> Sometimes you have a bit of each :-)
> 
> Have a look at the postgresql-13 source package for Bullseye [2]: I
> count 13 binary packages generated from that :-)

For one that often comes to my attention, look at systemd. Looking at
the Package-List field visible from 'apt-cache showsrc systemd' on
current-as-of-a-week-or-so-ago testing, I count 19 binary packages,
including three which are related to udev and not to systemd at all
(although for... some reason... systemd-the-project has decided to treat
udev as just another component of systemd-the-suite, and so it gets
included in the same single source package these days).

More relevantly to this thread, the equivalent check with 'apt-cache
showsrc grub2' (since grub2 is the source-package name for the packages
named in the CVE mentioned by debsecan, according to the OP) shows 49
binary packages - no, that's not a typo, one short of fifty. Most of
them follow the pattern of [name], [name]-bin, and [name]-dbg, but there
are some outliers.

If any of those are installed (or possibly even just not purged?) on the
machine in question, that might explain why debsecan shows the CVE as
being applicable.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: Interpreting debsecan output

[tomas]

On Fri, Nov 04, 2022 at 02:52:29PM -, Curt wrote:
> On 2022-11-02, Andy Smith  wrote:
> >
> > So why is debsecan reporting this as a security issue?
> >
> > This is a very old host that has been continually upgraded since Debian
> 
> I don't really know, but maybe because 
> 
>  Much like the official Debian security advisories, debsecan's
>  vulnerability tracking is mostly based on source packages. This can be
>  confusing because tools like dpkg only display binary package names.
>  Therefore, debsecan displays the more familiar binary package names.
>  This has the unfortunate effect that all binary packages (including
>  packages containing only documentation, for example) are flagged as
>  vulnerable, and not only those packages which actually contain the
>  vulnerable code.
> 
> I don't even understand that paragraph! Sorry for the interruption!

One source package may give birth to several binary packages.
Typically you have at least three .deb -- the "business end"
containing the binary (or library, or whatever), the -doc
(which is typically packaged separately to the benefit of those
with tight space requirements [1], and the -dev, with all the
relevant headers for when you want to compile things against
this package.

Sometimes you have a client/server package (think, e.g. PostgreSQL),
where you want to be able to install clients and servers separately.

Sometimes you have one source package which can produce different
flavours of binary (think Emacs: -nox for no GUI, GTK, Lucid,
etc. for different GUI widget sets).

Sometimes you have a bit of each :-)

Have a look at the postgresql-13 source package for Bullseye [2]:
I count 13 binary packages generated from that :-)

Cheers

[1] More use cases come to mind: e.g. if you install for several
   different architectures, you don't want the same doc several
   times, etc.
[2] https://packages.debian.org/source/bullseye/postgresql-13

-- 
t


signature.asc
Description: PGP signature

Re: Interpreting debsecan output

[Curt]

On 2022-11-02, Andy Smith  wrote:
>
> So why is debsecan reporting this as a security issue?
>
> This is a very old host that has been continually upgraded since Debian

I don't really know, but maybe because 

 Much like the official Debian security advisories, debsecan's
 vulnerability tracking is mostly based on source packages. This can be
 confusing because tools like dpkg only display binary package names.
 Therefore, debsecan displays the more familiar binary package names.
 This has the unfortunate effect that all binary packages (including
 packages containing only documentation, for example) are flagged as
 vulnerable, and not only those packages which actually contain the
 vulnerable code.

I don't even understand that paragraph! Sorry for the interruption!

Interpreting debsecan output

[Andy Smith]

Hello,

Today I was looking at "debsecan" for the first time. It has sent me a
very long daily report containing entries such as:

CVE-2021-3695 A crafted 16-bit grayscale PNG image may lead to a...
  
  - grub-common, grub-pc, grub-pc-bin, grub2-common

I'm having troulbe understanding why it is reporting things such as
the above. Looking at the link provided, I see:

Release Version Status
bullseye2.06-3~deb11u1  fixed

I have newer versions installed:

$ dpkg-query -l grub-common grub-pc grub-pc-bin grub2-common
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   VersionArchitecture Description
+++-==-==--=
ii  grub-common2.06-3~deb11u2 i386 GRand Unified Bootloader (common 
files)
ii  grub-pc2.06-3~deb11u2 i386 GRand Unified Bootloader, 
version 2 (PC/BIOS version)
ii  grub-pc-bin2.06-3~deb11u2 i386 GRand Unified Bootloader, 
version 2 (PC/BIOS modules)
ii  grub2-common   2.06-3~deb11u2 i386 GRand Unified Bootloader (common 
files for version 2)

So why is debsecan reporting this as a security issue?

This is a very old host that has been continually upgraded since Debian
etch. At first debsecan included lots of complaints about removed
packages from earlier releases that had been left around after doing
dist-upgrade (Desired/Status='rc' in dpkg terms). I went through and
purged all of those so I believe there's only bullseye packages
remaining now, and that did reduce debsecan's output a lot, but I'm
having trouble understanding why it still mentions things like the
above.

Any ideas?

Thanks,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting