Re: freeimage and CVE-2019-12214
Hi Santiago,
Here's some follow up :-)
Best regards,
Cyrille
Le mardi 16 avril 2024 à 12:52 -0300, Santiago Ruano Rincón a écrit :
> Hi Cyrille,
>
> El 16/04/24 a las 16:09, Cyrille Bollu escribió:
> > 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.
>
> And thanks for you help!
>
> > 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...?
>
> [...]
>
> Sorry if I was not verbose and clear enough in my previous messages.
> You
> are correct about saying that you have addressed these two
> hypothesis,
> but the problem is the information available to verify them relies
> *only* on the CVE description and its currently only reference:
> https://sourceforge.net/p/freeimage/discussion/36111/thread/e06734bed5/
>
> With a strong evidence I was thinking about a reproducer,
> confirmation
> from upstreams, or a stack trace, as Hugo mentioned in the note he
> added
> in the security-tracker:
> https://security-tracker.debian.org/tracker/CVE-2019-12214
I will try to contact openjpeg's maintainers to seek confirmation...
> Other than the available descriptions, how can be 100% sure the code
> refactoring made with openjpeg2 2.1.0-1 clearly fixes the out-of-
> bound
> access? We are only assuming the issue is in an embedded copy of
> openjpeg2, and there is a commit that could have fixed it. I would
> like
> to insist that we prefer to be wrong on the safe side, keeping an
> issue
> open (rather than claiming it is fixed without a more clear evidence)
> and continue to track it.
Hmmm, I'm not sure I understand you correclty, but I wonder how a
vulnerability of a function in a library could still affect the library
when this function has been removed.... But, maybe you want to make
sure that they didn't re-created the "same" vulnerability in another
function, which would be a valid concern, I agree... Otherwise, I
probably don't understand enough about C libraries to understand the
problem here...
>
> However, I would like to mention *I* think it was worth to inform
> MITRE
> about the code mentioned in the CVE description was found in an
> embedded
> copy of openjpeg2 in freeimage (So thank you for that!). But it is
> likely that the security team has a different opinion about this.
Which security team are you talking about? MITRE's? I believe they must
have to agree that the vulnerability affects both freeimage and
openjpeg2. So, the CPE of this CVE should be something like:
- cpe:2.3:a:freeimage_project:freeimage:3.18.0:*:*:*:*:*:*:*
- cpe:2.3:a:uclouvain:openjpeg:2.0:*:*:*:*:*:*:*
- cpe:2.3:a:uclouvain:openjpeg:2.0.0:*:*:*:*:*:*:*
- cpe:2.3:a:uclouvain:openjpeg:2.0.1:*:*:*:*:*:*:*
see also
https://nvd.nist.gov/products/cpe/search/results?namingFormat=2.3&keyword=openjpeg
>
> I hope this brings some light to the issue.
>
> > I hope my questions are not totally off-topic and that they bring
> > something to the discussion.
>
> Your questions are completely on-topic. Thank you for asking!
>
> Cheers,
>
> -- Santiago
>
Reply to: