Re: freeimage and CVE-2019-12214
Hi Santiago,
>It is not a question of trust. It is a problem of lack of strong
>evidence that the issue is no longer there in freeimage or openjepg2.
>We cannot rely only on CVE description to track the issues.
I think you'd be right to not trust my analysis too lightly since it's
my first contribution here. And, not knowing your practices at all, I
might easily have overlooked things indeed.
That being said, I'm not sure I agree with you that we lack "strong
evidence that the issue is no longer there in freeimage or openjepg2".
Reading your sentence, I understand that there are 2 things to be
proven:
1. That the freeimage package (in Debian Buster, FWR Debian LTS) is not
affected by this vulnerability;
2. That the openjpeg2 package (in Debian Buster, FWR Debian LTS) is not
affected by this vulnerability
As I believe these 2 concerns have been addressed, I'm wondering if you
are thinking of something else...?
Let me now summarize why I believe these 2 concerns have been
addressed:
1. Regarding Debian's freeimage package
=======================================
I believe that proof has been made that Debian's freeimage package in
Buster is using the openjpeg2's system libraries, hence that this CVE
cannot be assigned to this package. Don't you agree?
2. Regarding Debian's openjpeg2 package
==========================================
The vulnerability is reported in function j2k_read_ppm_v3 in file
j2k.c. That function has been completely removed from this file. In
such case, I wonder how this CVE would still apply to this library. Am
I missing something?
I hope my questions are not totally off-topic and that they bring
something to the discussion.
Best regards,
Cyrille
Le lundi 15 avril 2024 à 18:32 -0300, Santiago Ruano Rincón a écrit :
> Hi,
>
> El 15/04/24 a las 21:47, Ola Lundqvist escribió:
> > Hi Santiago
> >
> > On Mon, 15 Apr 2024 at 21:10, Santiago Ruano Rincón
> > <santiagorr@riseup.net> wrote:
> > >
> > > Hi Ola,
> > >
> > > As being discussed with Salvatore, there is not enough evidence
> > > to
> > > conclude there is not any issue present on the freeimage side.
> >
> > Do I understand correctly that the evidence that Cyrille provided
> > is not enough?
>
> > From the different inputs available, *I* would add this issue as
> affecting openjpeg2 for being able to track it there too. And I would
> wait for the response by MITRE. I have not confirmed Salvatore or the
> Securiy Team shares that opinion, though.
>
> I don't have at hand anything that clearly tells me the issue is no
> longer present after openjpeg2 2.1.0-1.
>
> > > We need
> > > to be on the safe side, like *always*, and with marking freeimage
> > > as
> > > <not-affected> we would stop tracking the issue.
> > > To stay on the safe side, we need to keep tracking the issue.
> >
> > If we do not trust that analysis from Cyrille, I agree with you.
>
> It is not a question of trust. It is a problem of lack of strong
> evidence that the issue is no longer there in freeimage or openjepg2.
> We
> cannot rely only on CVE description to track the issues.
>
> > > Hugo mentioned this refactoring commit that *could* have fixed
> > > the issue:
> > > https://github.com/uclouvain/openjpeg/commit/c887df12a38ff1a2721d0c8a93b74fe1d02701a2
> > > Ref:
> > > https://sourceforge.net/p/freeimage/discussion/36111/thread/e06734bed5/#b887/4639
> > > But without any reproducer, it is hard to conclude the issue was
> > > fixed.
> >
> > Yes without a reproducer we cannot tell with absolute certainty,
> > unless we create a new reproducer.
>
> And marking a package as <not-affected> by an issue requires to have
> absolute certainty.
>
> > > One possibility would be to mark it as <ignored>, but not as
> > > <not-affected>.
> >
> > That is a possibility, yes. Is this what you propose then?
>
> If you propose to create a new reproducer; so I would not mark it as
> <ignored> :-)
>
> > > <postponed> wouldn't make sense since the reported
> > > hasn't shared any more information in five years.
> >
> > That was new to me. I thought we did not <ignore> issues purely
> > because we have not more info.
> > But I agree with you that ignoring really old things for which we
> > have
> > no more info makes sense.
> > I was not aware that it was an ok thing to do.
>
> The above was a suggestion made by Salvatore and I cannot talk for
> the
> security team. This is just one possible action. My understanding,
> for
> this kind of cases, is marking it as <ignored> where there is
> **really**
> nothing else we can do, while still tracking the issue. But if you
> are
> able to reproduce the issue, or provide more information, leaving it
> as
> open (until we can conclude something different) makes equally sense.
>
> HTH,
>
> -- Santiago
>
Reply to: