Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1197741 > unrolled thread

Bug#1071276: Is 1:1.2.13.dfsg-1 affected by CVE-2023-45853, and if it is, will 1:1.3.dfsg-3.1 be backported to bookworm?

Back to article view | Back to linux.debian.bugs.dist

Contents

  Bug#1071276: Is 1:1.2.13.dfsg-1 affected by CVE-2023-45853, and if it is, will 1:1.3.dfsg-3.1 be backported to bookworm? John Waffle <jwaffe75@gmail.com> - 2024-05-17 16:50 +0200
    Bug#1071276: Is 1:1.2.13.dfsg-1 affected by CVE-2023-45853, and if it is, will 1:1.3.dfsg-3.1 be backported to bookworm? Mark Brown <broonie@debian.org> - 2024-05-17 17:00 +0200
      Bug#1071276: Is 1:1.2.13.dfsg-1 affected by CVE-2023-45853, and if it is, will 1:1.3.dfsg-3.1 be backported to bookworm? John Waffle <jwaffe75@gmail.com> - 2024-05-17 17:10 +0200
        Bug#1071276: Is 1:1.2.13.dfsg-1 affected by CVE-2023-45853, and if it is, will 1:1.3.dfsg-3.1 be backported to bookworm? Mark Brown <broonie@debian.org> - 2024-05-17 17:10 +0200
    Bug#1071276: Is 1:1.2.13.dfsg-1 affected by CVE-2023-45853, and if it is, will 1:1.3.dfsg-3.1 be backported to bookworm? Salvatore Bonaccorso <carnil@debian.org> - 2024-05-17 18:20 +0200
      Bug#1071276: Is 1:1.2.13.dfsg-1 affected by CVE-2023-45853, and if it is, will 1:1.3.dfsg-3.1 be backported to bookworm? John Waffle <jwaffe75@gmail.com> - 2024-05-17 22:10 +0200
        Bug#1071276: Is 1:1.2.13.dfsg-1 affected by CVE-2023-45853, and if it is, will 1:1.3.dfsg-3.1 be backported to bookworm? Salvatore Bonaccorso <carnil@debian.org> - 2024-05-18 11:10 +0200
          Bug#1071276: Is 1:1.2.13.dfsg-1 affected by CVE-2023-45853, and if it is, will 1:1.3.dfsg-3.1 be backported to bookworm? John Waffle <jwaffe75@gmail.com> - 2024-05-22 16:10 +0200
            Bug#1071276: Is 1:1.2.13.dfsg-1 affected by CVE-2023-45853, and if it is, will 1:1.3.dfsg-3.1 be backported to bookworm? John Waffle <jwaffe75@gmail.com> - 2024-05-24 20:10 +0200
              Bug#1071276: Is 1:1.2.13.dfsg-1 affected by CVE-2023-45853, and if it is, will 1:1.3.dfsg-3.1 be backported to bookworm? Salvatore Bonaccorso <carnil@debian.org> - 2024-05-24 21:50 +0200

#1197741 — Bug#1071276: Is 1:1.2.13.dfsg-1 affected by CVE-2023-45853, and if it is, will 1:1.3.dfsg-3.1 be backported to bookworm?

[Multipart message — attachments visible in raw view] — view raw

Package: zlib
Version: 1:1.2.13.dfsg-1

Related bug reports:
- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1054290
- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1056718

These were marked as resolved but it seems like I'm getting some
contradictory information.

- The zlib package page https://tracker.debian.org/pkg/zlib says that
CVE-2023-45853 <https://security-tracker.debian.org/tracker/CVE-2023-45853>
is ignored, what is the basis for ignoring this CVE?
- Is there a plan to backport zlib 1:1.3.dfsg-3.1 to bookworm? It looks
like it's currently in trixie

The maintainer of zlib said this in a comment
https://github.com/madler/zlib/pull/843#issuecomment-2050417533

> Sigh. I tried.

> It is this page:
https://security-tracker.debian.org/tracker/CVE-2023-45853 , that
incorrectly marks 1:1.2.13.dfsg-1 as vulnerable, when in fact it has no
minizip code in it whatsoever. (I verified that by downloading it and
listing the external symbols in the .so file.) I managed to reach someone
at debian.org who seems to be in control of that page, but instead of
fixing the page, they defended it, even though it's wrong.

Can a Debian maintainer elaborate on this? Do the Debian maintainers feel
like this version of zlib is vulnerable or not?

If the Debian maintainers could confirm that this is not a real
vulnerability, maybe then we can get trivy to stop flagging this as a
critical vulnerability in their scan. This is a rather big problem because
a lot of images use Debian (bookworm specifically) and a lot of base images
(e.g. nginx) are getting flagged for this.

Thanks,

- J

[toc] | [next] | [standalone]

#1197742

[Multipart message — attachments visible in raw view] — view raw

On Fri, May 17, 2024 at 10:43:26AM -0400, John Waffle wrote:

> - The zlib package page https://tracker.debian.org/pkg/zlib says that
> CVE-2023-45853 <https://security-tracker.debian.org/tracker/CVE-2023-45853>
> is ignored, what is the basis for ignoring this CVE?
> - Is there a plan to backport zlib 1:1.3.dfsg-3.1 to bookworm? It looks
> like it's currently in trixie

Please direct any questions about security updates to the security team.

[toc] | [prev] | [next] | [standalone]

#1197743

[Multipart message — attachments visible in raw view] — view raw

Hi Mark,

How do I get in contact with them, should I just send a message to
security@debian.org?

Thanks,
- J

On Fri, May 17, 2024 at 10:54 AM Mark Brown <broonie@debian.org> wrote:

> On Fri, May 17, 2024 at 10:43:26AM -0400, John Waffle wrote:
>
> > - The zlib package page https://tracker.debian.org/pkg/zlib says that
> > CVE-2023-45853 <
> https://security-tracker.debian.org/tracker/CVE-2023-45853>
> > is ignored, what is the basis for ignoring this CVE?
> > - Is there a plan to backport zlib 1:1.3.dfsg-3.1 to bookworm? It looks
> > like it's currently in trixie
>
> Please direct any questions about security updates to the security team.
>

[toc] | [prev] | [next] | [standalone]

#1197744

[Multipart message — attachments visible in raw view] — view raw

On Fri, May 17, 2024 at 10:56:53AM -0400, John Waffle wrote:
> Hi Mark,
> 
> How do I get in contact with them, should I just send a message to
> security@debian.org?

Yes.

[toc] | [prev] | [next] | [standalone]

#1197753

Hi,

On Fri, May 17, 2024 at 10:43:26AM -0400, John Waffle wrote:
> Package: zlib
> Version: 1:1.2.13.dfsg-1
> 
> Related bug reports:
> - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1054290
> - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1056718
> 
> These were marked as resolved but it seems like I'm getting some
> contradictory information.
> 
> - The zlib package page https://tracker.debian.org/pkg/zlib says that
> CVE-2023-45853 <https://security-tracker.debian.org/tracker/CVE-2023-45853>
> is ignored, what is the basis for ignoring this CVE?
> - Is there a plan to backport zlib 1:1.3.dfsg-3.1 to bookworm? It looks
> like it's currently in trixie
> 
> The maintainer of zlib said this in a comment
> https://github.com/madler/zlib/pull/843#issuecomment-2050417533
> 
> > Sigh. I tried.
> 
> > It is this page:
> https://security-tracker.debian.org/tracker/CVE-2023-45853 , that
> incorrectly marks 1:1.2.13.dfsg-1 as vulnerable, when in fact it has no
> minizip code in it whatsoever. (I verified that by downloading it and
> listing the external symbols in the .so file.) I managed to reach someone
> at debian.org who seems to be in control of that page, but instead of
> fixing the page, they defended it, even though it's wrong.
> 
> Can a Debian maintainer elaborate on this? Do the Debian maintainers feel
> like this version of zlib is vulnerable or not?
> 
> If the Debian maintainers could confirm that this is not a real
> vulnerability, maybe then we can get trivy to stop flagging this as a
> critical vulnerability in their scan. This is a rather big problem because
> a lot of images use Debian (bookworm specifically) and a lot of base images
> (e.g. nginx) are getting flagged for this.

Again, the notes explain the tracking; The zlib is *source* in the
security-tracker not the binary package produced. Thus the entry reads
as:

        - zlib 1:1.3.dfsg-2 (bug #1054290)
        [bookworm] - zlib <ignored> (contrib/minizip not built and producing binary packages)
        [bullseye] - zlib <ignored> (contrib/minizip not built and producing binary packages)
        [buster] - zlib <ignored> (contrib/minizip not built and producing binary packages)

is there in the wording which you think needs improvement?

Why does your security-scanner not consider the information gathered
by the security-tracker including the 'ignored' state there? Can you
bring that to your vendor of the security scanner?

Regards,
Salvatore

[toc] | [prev] | [next] | [standalone]

#1197772

[Multipart message — attachments visible in raw view] — view raw

This report came from a free tool, trivy, I filed a Github discussion about
it here: https://github.com/aquasecurity/trivy/discussions/6722

On Fri, May 17, 2024 at 12:08 PM Salvatore Bonaccorso <carnil@debian.org>
wrote:

> Hi,
>
> On Fri, May 17, 2024 at 10:43:26AM -0400, John Waffle wrote:
> > Package: zlib
> > Version: 1:1.2.13.dfsg-1
> >
> > Related bug reports:
> > - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1054290
> > - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1056718
> >
> > These were marked as resolved but it seems like I'm getting some
> > contradictory information.
> >
> > - The zlib package page https://tracker.debian.org/pkg/zlib says that
> > CVE-2023-45853 <
> https://security-tracker.debian.org/tracker/CVE-2023-45853>
> > is ignored, what is the basis for ignoring this CVE?
> > - Is there a plan to backport zlib 1:1.3.dfsg-3.1 to bookworm? It looks
> > like it's currently in trixie
> >
> > The maintainer of zlib said this in a comment
> > https://github.com/madler/zlib/pull/843#issuecomment-2050417533
> >
> > > Sigh. I tried.
> >
> > > It is this page:
> > https://security-tracker.debian.org/tracker/CVE-2023-45853 , that
> > incorrectly marks 1:1.2.13.dfsg-1 as vulnerable, when in fact it has no
> > minizip code in it whatsoever. (I verified that by downloading it and
> > listing the external symbols in the .so file.) I managed to reach someone
> > at debian.org who seems to be in control of that page, but instead of
> > fixing the page, they defended it, even though it's wrong.
> >
> > Can a Debian maintainer elaborate on this? Do the Debian maintainers feel
> > like this version of zlib is vulnerable or not?
> >
> > If the Debian maintainers could confirm that this is not a real
> > vulnerability, maybe then we can get trivy to stop flagging this as a
> > critical vulnerability in their scan. This is a rather big problem
> because
> > a lot of images use Debian (bookworm specifically) and a lot of base
> images
> > (e.g. nginx) are getting flagged for this.
>
> Again, the notes explain the tracking; The zlib is *source* in the
> security-tracker not the binary package produced. Thus the entry reads
> as:
>
>         - zlib 1:1.3.dfsg-2 (bug #1054290)
>         [bookworm] - zlib <ignored> (contrib/minizip not built and
> producing binary packages)
>         [bullseye] - zlib <ignored> (contrib/minizip not built and
> producing binary packages)
>         [buster] - zlib <ignored> (contrib/minizip not built and producing
> binary packages)
>
> is there in the wording which you think needs improvement?
>
> Why does your security-scanner not consider the information gathered
> by the security-tracker including the 'ignored' state there? Can you
> bring that to your vendor of the security scanner?
>
> Regards,
> Salvatore
>

[toc] | [prev] | [next] | [standalone]

#1197831

Hi John,

On Fri, May 17, 2024 at 04:01:56PM -0400, John Waffle wrote:
> This report came from a free tool, trivy, I filed a Github discussion about
> it here: https://github.com/aquasecurity/trivy/discussions/6722

Thanks a lot for bringing that upstream.

So to add some additional datapoint: The issue araises here by maybe
thinking zlib refers to the binary package produced. It is correct,
for the binary package zlib then indeed you would not be vulnerable. 

Let me as well elaborate on the "ingored". This comes as the binary
packages built from the *vulnerable* source, there is no point to
force an update in bookworm and older.

I hope this all get a better picture now on the CVE. If you still have
questions feel free to ask.

Regards,
Salvatore

[toc] | [prev] | [next] | [standalone]

#1198271

[Multipart message — attachments visible in raw view] — view raw

Hello,

I got a response from trivy,
https://github.com/aquasecurity/trivy/discussions/6722#discussioncomment-9518531

> Helllo @superlazyname <https://github.com/superlazyname>
> Thanks for your report!

> As you can see - we marked this vulnerability as "Status": "will_not_fix",
.
> We use will_not_fix for vulnerabilities with ignored State.
> We can't parse State description, because it deoesn't have format.

> [bookworm] - zlib (contrib/minizip not built and producing binary
packages)

> It seems that debian chose wrong state. not_affected looks more correct.
------------------------------

> Trivy supports VEX
<https://aquasecurity.github.io/trivy/v0.51/docs/supply-chain/vex/>.
> You can create VEX file to ignore this CVE.

> Regards, Dmitriy

I'll call out these particular points,

> We can't parse State description, because it doesn't have format.

> It seems that debian chose wrong state. not_affected looks more correct.

It sounds like this is some kind of incompatibility between how trivy
conceptualizes CVEs vs how Debian conceptualizes CVEs, plus a terminology
problem on the meaning of "ignored" (won't fix vs is not affected)

- Would you consider marking the vulnerability as "not_affected" instead of
"ignored"? Or does the Debian CVE tracking system not support that?

- I would agree that " [bookworm] - zlib (contrib/minizip not built and
producing binary packages)" doesn't have a standard format, but is there no
other viable way for a scanner to pick up on the CVE being ignored?

- Do you have docs to show what method should be used to properly handle
this issue being marked as "ignored"? Do you have any sample code / script
snippets you can share with me? Maybe I can submit a PR?

Maybe there is some way for trivy to notice that the issue is "ignored" and
then, for only Debian, interpret that as not_affected.

- John

On Sat, May 18, 2024 at 5:03 AM Salvatore Bonaccorso <carnil@debian.org>
wrote:

> Hi John,
>
> On Fri, May 17, 2024 at 04:01:56PM -0400, John Waffle wrote:
> > This report came from a free tool, trivy, I filed a Github discussion
> about
> > it here: https://github.com/aquasecurity/trivy/discussions/6722
>
> Thanks a lot for bringing that upstream.
>
> So to add some additional datapoint: The issue araises here by maybe
> thinking zlib refers to the binary package produced. It is correct,
> for the binary package zlib then indeed you would not be vulnerable.
>
> Let me as well elaborate on the "ingored". This comes as the binary
> packages built from the *vulnerable* source, there is no point to
> force an update in bookworm and older.
>
> I hope this all get a better picture now on the CVE. If you still have
> questions feel free to ask.
>
> Regards,
> Salvatore
>

[toc] | [prev] | [next] | [standalone]

#1198481

[Multipart message — attachments visible in raw view] — view raw

Hello,

I was thinking about this a bit more and I had a question,

> Let me as well elaborate on the "ingored". This comes as the binary
packages built from the *vulnerable* source, there is no point to force an
update in bookworm and older.

It sounds like Debian uses the "ignored" state to mean "this bug does not
affect the Debian package".

Is there another state that's used to indicate "won't fix"? Can we assume
that "ignored" always means "won't fix"? Or can "ignored" mean either thing
and we'd have to look in the notes to know for sure?

Thanks,
- J

On Wed, May 22, 2024 at 9:56 AM John Waffle <jwaffe75@gmail.com> wrote:

> Hello,
>
> I got a response from trivy,
> https://github.com/aquasecurity/trivy/discussions/6722#discussioncomment-9518531
>
> > Helllo @superlazyname <https://github.com/superlazyname>
> > Thanks for your report!
>
> > As you can see - we marked this vulnerability as "Status":
> "will_not_fix",.
> > We use will_not_fix for vulnerabilities with ignored State.
> > We can't parse State description, because it deoesn't have format.
>
> > [bookworm] - zlib (contrib/minizip not built and producing binary
> packages)
>
> > It seems that debian chose wrong state. not_affected looks more correct.
> ------------------------------
>
> > Trivy supports VEX
> <https://aquasecurity.github.io/trivy/v0.51/docs/supply-chain/vex/>.
> > You can create VEX file to ignore this CVE.
>
> > Regards, Dmitriy
>
> I'll call out these particular points,
>
> > We can't parse State description, because it doesn't have format.
>
> > It seems that debian chose wrong state. not_affected looks more correct.
>
> It sounds like this is some kind of incompatibility between how trivy
> conceptualizes CVEs vs how Debian conceptualizes CVEs, plus a terminology
> problem on the meaning of "ignored" (won't fix vs is not affected)
>
> - Would you consider marking the vulnerability as "not_affected" instead
> of "ignored"? Or does the Debian CVE tracking system not support that?
>
> - I would agree that " [bookworm] - zlib (contrib/minizip not built and
> producing binary packages)" doesn't have a standard format, but is there no
> other viable way for a scanner to pick up on the CVE being ignored?
>
> - Do you have docs to show what method should be used to properly handle
> this issue being marked as "ignored"? Do you have any sample code / script
> snippets you can share with me? Maybe I can submit a PR?
>
> Maybe there is some way for trivy to notice that the issue is "ignored"
> and then, for only Debian, interpret that as not_affected.
>
> - John
>
> On Sat, May 18, 2024 at 5:03 AM Salvatore Bonaccorso <carnil@debian.org>
> wrote:
>
>> Hi John,
>>
>> On Fri, May 17, 2024 at 04:01:56PM -0400, John Waffle wrote:
>> > This report came from a free tool, trivy, I filed a Github discussion
>> about
>> > it here: https://github.com/aquasecurity/trivy/discussions/6722
>>
>> Thanks a lot for bringing that upstream.
>>
>> So to add some additional datapoint: The issue araises here by maybe
>> thinking zlib refers to the binary package produced. It is correct,
>> for the binary package zlib then indeed you would not be vulnerable.
>>
>> Let me as well elaborate on the "ingored". This comes as the binary
>> packages built from the *vulnerable* source, there is no point to
>> force an update in bookworm and older.
>>
>> I hope this all get a better picture now on the CVE. If you still have
>> questions feel free to ask.
>>
>> Regards,
>> Salvatore
>>
>

[toc] | [prev] | [next] | [standalone]

#1198493

Hi John,

On Fri, May 24, 2024 at 01:57:01PM -0400, John Waffle wrote:
> Hello,
> 
> I was thinking about this a bit more and I had a question,
> 
> > Let me as well elaborate on the "ingored". This comes as the binary
> packages built from the *vulnerable* source, there is no point to force an
> update in bookworm and older.
> 
> It sounds like Debian uses the "ignored" state to mean "this bug does not
> affect the Debian package".
> 
> Is there another state that's used to indicate "won't fix"? Can we assume
> that "ignored" always means "won't fix"? Or can "ignored" mean either thing
> and we'd have to look in the notes to know for sure?

Thanks for the query.
https://security-team.debian.org/security_tracker.html#issues-not-warranting-a-security-advisory
explains how <ignored> is to be interpreted when encountered. I think
security-scanner encountering it can classify it accordingly so that
no flag is raised.

Hope that helps,

Regards,
Salvatore

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web