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? > > 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
signature.asc
Description: PGP signature
