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 >
