[Debian-astro-maintainers] Bug#1087911: Bug#1087911:

[Ajin Deepak]

Hi,

To address your first question, in the context of *dcraw*, a denial of
service (DoS) vulnerability refers to the software's inability to handle
malformed files appropriately. A specially crafted file can cause the
application to crash, disrupting its functionality for users relying on it
for image processing. While it is not a networked "service," this still
constitutes a DoS as it prevents the intended use of the tool.
Additionally, the issue highlighted here involves a memory leak. This leak
exposes memory addresses that could assist in exploiting other
vulnerabilities, such as buffer overflows.


Apologies for the confusion earlier regarding multi-user systems—I was
referring to scenarios involving privilege escalation. Tools installed by
the root user often have elevated privileges or capabilities, especially if
they run with *setuid* permissions or interact with privileged system
components. If such a tool has vulnerabilities and is executed by a
non-privileged user, exploiting it could escalate the attacker's privileges
to root or other users, as in the scenarios you mentioned.

Regarding the difference between memory leaks in a browser and a standalone
tool like *dcraw*, you are correct: in a browser, a user might
inadvertently visit a malicious website after accessing sensitive pages,
which poses an immediate risk. With *dcraw*, a user would need to receive
and intentionally open a malformed file. But even in CVE it's an
uninitialized memory leak, these are not exploitable by just visiting a
webpage .However, even if such cases are not immediately exploitable,
patching these issues is essential. Left unaddressed, they could
potentially aid exploitation when combined with other vulnerabilities in a
chain.

And yes I did apply for CVE after your reply.



On Fri, Nov 22, 2024 at 12:10 AM Thorsten Alteholz <debian at alteholz.de>
wrote:

> On 21.11.24 15:32, Ajin Deepak wrote:
>
>
>
>
>
>
>  While dcraw is a standalone CLI tool, it can be integrated into other
> software. For example, I saw RawTherapee using dcraw.
>
>
> yes, whatever, this is a pretty UI around dcraw, but it is still software
> that a user executes. I repeat my question: What service can suffer under a
> denial of service attack as you stated in your first email.
>
>
> Address leaks or memory leaks in tools like dcraw could expose sensitive
> memory data when run in multi-user systems, potentially aiding attackers in
> other exploits such as bypassing ASLR.
>
>
> Ok, fine, you need to be able to trick a user to open a special crafted
> file and than you  are able to get information about the process the user
> just started. You are aware that each process gets its own memory space
> which is not accessible from other user space processes, aren't you? So why
> do you even mention multi-user systems here?
>
> Let me show you an similar CVE which had a memory leak
> https://www.cve.org/CVERecord?id=CVE-2024-7526
>
>
> I think there is a difference in a memory leak of a browser, where you can
> "accidentally" open a malformed website after you already visited other
> webpages with sensitive information and a memory leak in a software, where
> you need to receive a malformed file from an attacker and open this file
> with dcraw.
> Anyway, the NVD base score of this CVE is 6.5, how worrisome. Of course
> this is a bug that needs to be fixed, but none that needs any immediate
> action.
>
>
> You can find a number of them in cve.org.
>
> There are a lot of CVEs for CLI tools. For example:
>
>    - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4799
>
>
> Hmm, NVD base score of 4.3 ...
>
>
>    - https://www.cve.org/CVERecord?id=CVE-2024-7867
>
>
> ... NVD base score of 6.3. This was already evaluated with CVSS 4.0 and
> got a score of 2.1. I don't think these are good examples to support your
> argument about a critical security vulnerability in dcraw.
>
> That was also the reason why I asked whether you already applied for a CVE
> for your issue. Did you already get one?
>
>   Thorsten
>
>
>
>
>    -
>
> I understand your concern and thanks for your patience
>
> _______________________________________________
> Debian-astro-maintainers mailing listDebian-astro-maintainers at alioth-lists.debian.nethttps://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-astro-maintainers
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/debian-astro-maintainers/attachments/20241122/22a21b87/attachment-0001.htm>