Re: How to handle freeimage package
Hi Adrian
See below.
On Thu, 11 Apr 2024 at 22:46, Adrian Bunk <bunk@debian.org> 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
> > <santiagorr@riseup.net> 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 ----
| ola@inguza.com opal@debian.org |
| http://inguza.com/ Mobile: +46 (0)70-332 1551 |
---------------------------------------------------------------
Reply to: