Hi Adrian See below.
On Thu, 11 Apr 2024 at 22:46, Adrian Bunk <[email protected]> wrote: > > On Thu, Apr 11, 2024 at 09:34:00PM +0200, Ola Lundqvist wrote: > >... > > On Thu, 11 Apr 2024 at 15:34, Santiago Ruano Rincón > > <[email protected]> wrote: > > ... > > > Taking one of the recent changes to data/CVE/list: > > > > > > @@ -6999,6 +7000,7 @@ CVE-2024-28579 (Buffer Overflow vulnerability in > > > open source FreeImage v.3.19.0 > > > - freeimage <unfixed> (bug #1068461) > > > [bookworm] - freeimage <no-dsa> (Revisit when fixed upstream) > > > [bullseye] - freeimage <no-dsa> (Revisit when fixed upstream) > > > + [buster] - freeimage <postponed> (Revisit when fixed upstream, > > > low severity DoS in tool) > > > NOTE: > > > https://github.com/Ruanxingzhi/vul-report/tree/master/freeimage-r1909 > > > > > > Are you completely sure the related buffer overflow doesn't make > > > possible to cause arbitrary code execution. > > > > Can one be completely sure about anything? So, no I'm not completely > > sure. I have worked long enough to learn that even if I think I'm > > right I may not be. > > The only thing you can be sure about is that the PoC reproduces the CVE > without your fix, and does no longer reproduce it with your fix. Yes > > I'm pretty sure that the ones that mention code execution are more severe. > >... > > I'm pretty sure this is not a realistic assumption. Hmm > Everyone who has done CVE fixing in recent years knows that fuzzer CVEs > are relatively nice to handle since they usually come with a PoC and > tend to have a short fix, I agree to that. But in this case there were no patch. I merely postpone it until there is a patch. > but the CVE descriptions are often garbage > since many of the CVE reporters do not have any clue how an exploit > would work. That is a point. So you mean that we should not trust the CVE descriptions at all. Well that certainly makes triaging more complicated, especially in the case where information is sparse. These descriptions seemed quite well thought through so I thought I could trust that description. What I typically do is to read the description, and the referenced material to see if the reporter seems to make sense. If there is a fix available read the fix. The fix typically give a lot of information. In this case there were no fix, only a reproducer and backtrace description. They seemed to make sense and therefore I postponed the ones that were mentioned as DoS class in the same way as the other issues had been postponed when they were of the same class. As you can see I have now followed up this with removing the postpone tag for things that do in fact have a patch available. Please note that I kept the text that it should be revisited when patches are available. That still applies. Cheers // Ola -- --- Inguza Technology AB --- MSc in Information Technology ---- | [email protected] [email protected] | | http://inguza.com/ Mobile: +46 (0)70-332 1551 | ---------------------------------------------------------------
