Re: How to handle freeimage package
Hi Santiago
Cutting down the commented part since it is rather long.
On Thu, 11 Apr 2024 at 15:34, Santiago Ruano Rincón
<santiagorr@riseup.net> wrote:
...
>
> The fact of claiming a package to avoid double-work is not the problem I
> see. What brought my attention was the way you said you were working on
> freeimage. Let me highlight this: "My intention for claiming the package
> was to go through the CVEs and mark them with postponed or similar. When
> I'm done with that maybe I will start to fix things..."
>
>
> I would rather have said something like: "My intention for claiming the
> package was to solve as many fixes as possible, including those that
> have been previously marked as posponed or no-dsa. As discussed during
> an LTS Team meeting some months ago, I am planning to release an update
> with a batch of issues, since I see it is not possible to fix all the
> open issues. If needed and where applicable, I will also propose an
> update for {old,}stable. While I work on the fixes, I will revisit the
> triaging if required".
>
> I think the above could be applied as a general rule. And for the current
> freeimage case, I would say this: "My intention for claiming freeimage
> is now to follow suggestion by Mortiz to report in the upstream BTS
> those issues that are not there, then to backport the patches that I can
> find available, then to propose patches where possible. I will also
> propose updates for bookworm and bullseye for the same issues I can
> tackle in buster, especially in this case where the three releases share
> the same version. While I work on the fixes, I will revisit the triaging
> if required".
Well if I have the time, yes.
My intention was to merely document what I had already found out. I
had stumbled on that when going through the list.
Essentially that a fairly large number of them are "local DoS" class
and therefore they could be postponed.
So I claimed it to avoid someone else do the same thing at that point in time.
If I have time over, I would then go through the list of higher
priority packages first to check
for more important problems.
If I do not find anything more important, then yes I would have done that.
That was what I was referring to when I wrote:
"When I'm done with that maybe I will start to fix things, but I
claimed it just to avoid double work when going through the issues."
I hope I do not do the wrong thing when going through things in priority order.
...
> > > Part of our mission is to help Debian users to have secure systems, and
> > > this includes interactive tools.
> >
> > Yes, but if you look at the Debian Security teams definition on what
> > defines the different severity levels there is a clear distinction
> > between that type of software is being used.
> >
> > https://security-team.debian.org/security_tracker.html#severity-levels
> >
> > For example see the difference between how the following two are classified:
> > * local DoS -> low
> > * Most remote DoS -> medium
>
> That is clear. But also consider that the security team states this:
> "These levels are mostly used to prioritize the order in which security
> problems are resolved".
Correct. This is why I think we can postpone those of low priority,
especially considering that that same package have more severe
problems already postponed.
What I was thinking of doing next, but being stopped by email
discussions, was to go through the currently postponed issues to check
if some of them should in fact not be postponed. Interactive arbitrary
code execution sounds something that should be corrected.
> > 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.
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.
I'm pretty sure that the ones that mention code execution are more severe.
> Are you 100% sure it is
> limited to a local DoS?
Almost. The reverse dependencies of the library package tell that all
of them are interactive tools. Yes I went through the whole list,
checking each of them what they were used for in the package
description. I did not run the commands though, so no completely sure
I cannot be.
>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.
It is not easy to follow all directions. The last I heard was that we
should motivate why we decide for postpone, so I tried to be as
verbose as possible on that single line.
Now you say that I should be less verbose.
If this is a consensus, sure I'll follow this direction too.
> Anyway, what I disagreed the most in your initial mail was this: "You
> run it with human interaction and **the user using the tool should know
> the input.**" No, you cannot expect the user using the tool knows they
> are opening a crafted image that could exploit a vulnerability.
The user should know the source of the file. If it is created by the
user itself it is safe. If it is from some untrusted source it is not.
This is why DoS class with user interaction is seen as a low issue,
because the worst thing that happen is that the program itself crashes
even on crafted files.
A code execution vulnerability after user interaction is medium
(normal) severity. I guess we should deal with them.
They are not high because social engineering, or similar, must be used
to trick someone to use that crafted file.
High issues should be dealt with the highest prio.
I hope my reasoning makes sense.
// Ola
> Cheers,
>
> -- Santiago
--
--- Inguza Technology AB --- MSc in Information Technology ----
| ola@inguza.com opal@debian.org |
| http://inguza.com/ Mobile: +46 (0)70-332 1551 |
---------------------------------------------------------------
Reply to: