Hi Ola,
El 11/04/24 a las 08:25, Ola Lundqvist escribió:
> On Thu, 11 Apr 2024 at 02:34, Santiago Ruano Rincón
> > El 10/04/24 a las 22:08, Ola Lundqvist escribió:
> > > Hi all
> > >
> > > Sorry for late reply. It took me too long today to answer the CVE
> > > triaging discussion. Now to this issue.
> > >
> > > Regarding the fedora patches. The patches seem to help for those
> > > specific issues they solve.
> > >
> > > 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, but I
> > > claimed it just to avoid double work when going through the issues.
> > >
> > > I'll start with that now and I hope I can release the package when I'm
> > > done with that. I'll re-claim it when/if I think they are worth
> > > fixing.
> >
> > IMHO, claiming a package means working at addressing the issues, fixing
> > them. (Re)Triaging of course can/must be done, for example to confirm if
> > the issue affects or not specific debian releases. So it reads weird to
> > claim a package to mark issues as postponed.
>
> So what other options do I have to avoid double work? I only planned
> to do it while doing the triaging and if I found any easy fixes I
> would do them, or at least provide patches.
> I see nothing wrong with claiming a package for a short while.
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".
> But if more people do not think we should use that practice I will
> stop that with the risk of double work being done.
>
> > > What is clear after checking all reverse dependencies is that all
> > > software packages using freeimage library are of the "tool" type. You
> > > run it with human interaction and the user using the tool should know
> > > the input. This reduces the severity of the problems.
> >
> > I am afraid I completely disagree with that. Malicious actors could take
> > advantage of security flaws (such as buffer overflows) in interactive
> > tools to, e.g., run arbitrary code, cause DoSs, etc. This is true for
> > PDFs readers, image processing tools, and etc.
>
> Yes, but it affects the severity of the problem. Remote arbitrary code
> execution is more severe than arbitrary code execution after human
> interaction.
> You can see that definition in the Debian Security team guidelines and
> in many other definitions on the severity.
>
> > 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".
> 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.
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.
Cheers,
-- Santiago
Attachment:
signature.asc
Description: PGP signature