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
