Re: freeimage and CVE-2019-12214
Hi,
On Fri, Apr 26, 2024 at 08:32:21PM +0200, Cyrille Bollu wrote:
>
>
> Le vendredi 26 avril 2024 à 12:50 -0300, Santiago Ruano Rincón a
> écrit :
> > Hi Cyrille!
> >
> > El 25/04/24 a las 15:00, Cyrille Bollu escribió:
> > > 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...
> >
> > I think that is not the point. Forget the CVE description and the
> > code
> > screenshot for a moment, both provided by the reporter; what other
> > element do you have to affirm whether there is (or not) a
> > vulnerability
> > somewhere in the code packaged in that upstream freeimage version?
>
> Oh, ok... I understand; I didn't question the original findings
> indeed...
>
> In this case, let's hope that openjpeg's maintainers will follow-up
> (https://groups.google.com/g/openjpeg/c/-qbT6yDsjmY) because I sure am
> not able to create a reproducer :-(
Please let us know once you hear from the openjpeg developers some
additional input.
Regards,
Salvatore
Reply to: