[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: freeimage and CVE-2019-12214




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 :-(

Cheers,

> 
> > > 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?
> 
> The Debian security team.
> 
> > 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
> ...
> 
> Cheers,
> 
>   -- S


Reply to: