Re: How to handle freeimage package
On Thu, Apr 11, 2024 at 10:34:13AM -0300, Santiago Ruano Rincón wrote:
>...
> El 11/04/24 a las 08:25, Ola Lundqvist escribió:
>...
> > The ones I have now postponed are of the "local DoS" class. I'm here
> > interpreting that "local DoS" is the same as DoS after human
> > interaction. It is not entirely accurate but similar enough for
> > triaging decision. See my other mail thread about triaging guide.
> >
> > I have not postponed any of the ones of type "permits code execution
> > after user interaction" yet.
>
> 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. Are you 100% sure it is
> limited to a local DoS? For being on the safe side, I would just left as
> note (Revisit when fixed upstream). Fellows doing FD work could also
> confirm if this is correct or not.
>...
"in tool" looks wrong in any case.
The 21 new CVEs were from a fuzzer who was using a trivial tool that
uses the library APIs to load and unload images:
https://github.com/Ruanxingzhi/vul-report/blob/master/freeimage-r1909/poc.c
(I assume poc.c is a polished version of the work.cpp in the traces)
> Cheers,
>
> -- Santiago
cu
Adrian
Reply to: