Bug#1087911: Change Severity

[Ajin Deepak]

severity 1087911 critical

I would like to request a change in the severity of bug report #1087911.

[Ajin Deepak]

Control: severity -1 critical

Dear Maintainer,

I would like to update the severity of bug #12345. The issue involves a
memory leak that causes the system to become unstable and crash, which
makes the package critical and warrants an immediate fix.

[Ajin Deepak]

Ajin Deepak <***@gmail.com>
7:59 PM (2 minutes ago)
to Debian
Hi,

Thank you for your response and for sharing your perspective on this issue.
I understand your concerns regarding the severity classification of the
memory leak in dcraw. Allow me to provide some additional context and
justification for treating this as a medium to critical issue. While dcraw is
a standalone CLI tool, it can be integrated into other software. For
example, I saw RawTherapee using dcraw.
https://github.com/Beep6581/RawTherapee?tab=readme-ov-file

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.
https://security.stackexchange.com/questions/22989/how-leaking-pointers-to-bypass-dep-aslr-works

Let me show you an similar CVE which had a memory leak
https://www.cve.org/CVERecord?id=CVE-2024-7526

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
- https://www.cve.org/CVERecord?id=CVE-2024-7867


I understand your concern and thanks for your patience

[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.

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.
- 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
_______________________________________________

[Thorsten Alteholz]

Hi,

Post by Ajin Deepak
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.

this sounds like the definition of a mere bug. I have never seen this
being called a DoS. Whatever, if you like to call it this way ...

Post by Ajin Deepak
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.

So what? Even if you are able to execute some code, you can only get
information from one user of the system. Back to the beginning of this
discussion: this looks like just an unimportant or minor issue and is far
away from the overhyped critical issue that you wanted to create in your
first mail.
Anybody who processes files from unknown sources of the internet has a
share of the blame in case bad things happen.

Post by Ajin Deepak
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.

Sure but this isn't related to dcraw, is it?

Post by Ajin Deepak
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.

No it is by far not essential. Applying a patch always involves the danger
of introducing a regression. It is by far worse to not be able to process
an image with dcraw at all than to have no fix for a fictional security
issue.

Post by Ajin Deepak
And yes I did apply for CVE after your reply.

Great, please share the number.

Thorsten

[Ajin Deepak]

Hi,

I understand your concerns. Here is the CVE number: 1775652

Post by Thorsten Alteholz
Hi,

Post by Ajin Deepak
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

Post by Ajin Deepak
for image processing. While it is not a networked "service," this still
constitutes a DoS as it prevents the intended use of the tool.

this sounds like the definition of a mere bug. I have never seen this
being called a DoS. Whatever, if you like to call it this way ...

Post by Ajin Deepak
Additionally, the issue highlighted here involves a memory leak. This

leak

Post by Ajin Deepak
exposes memory addresses that could assist in exploiting other
vulnerabilities, such as buffer overflows.

So what? Even if you are able to execute some code, you can only get
information from one user of the system. Back to the beginning of this
discussion: this looks like just an unimportant or minor issue and is far
away from the overhyped critical issue that you wanted to create in your
first mail.
Anybody who processes files from unknown sources of the internet has a
share of the blame in case bad things happen.

Post by Ajin Deepak
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

Post by Ajin Deepak
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

Post by Ajin Deepak
to root or other users, as in the scenarios you mentioned.

Sure but this isn't related to dcraw, is it?

Post by Ajin Deepak
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

Post by Ajin Deepak
chain.

No it is by far not essential. Applying a patch always involves the danger
of introducing a regression. It is by far worse to not be able to process
an image with dcraw at all than to have no fix for a fictional security
issue.

Post by Ajin Deepak
And yes I did apply for CVE after your reply.

Great, please share the number.
Thorsten

[Filip Hroch]

Dear Colleagues,

I have investigated and fixed the issue:

* Below is cited an instance of the desired behaviour, and the
reason,
why I wrote wrappers of fseek() and similar (introduced in
Debian's
version 9.28-3). The procedure finish by exit(1), and indicates
of a fail.
In this case, the memory is cleaned by the operating system
anyway.
I'am unsure about the core of the issue.

***@osboxes:~/Desktop$ dcraw [..] leak
fseek(0x5a1841ba9430, -2145648639,0): Invalid argument

* The leak indicated by fseek() is a trifle. The memory is
recovered
when dcraw exits --- dcraw, as an executable rather than a
library,
proves its design quality. The program block 472 bytes for a
while:

***@dell:/tmp/dcraw/dcraw$ valgrind ./dcraw /tmp/leak
==45177== Memcheck, a memory error detector
==45177== Copyright (C) 2002-2022, and GNU GPL'd, by Julian
Seward et al.
==45177== Using Valgrind-3.19.0 and LibVEX; rerun with -h for
copyright info
==45177== Command: ./dcraw /tmp/leak
==45177==
fseek(0x4c25250,-2145648639,0): Invalid argument
==45177==
==45177== HEAP SUMMARY:
==45177== in use at exit: 472 bytes in 1 blocks
==45177== total heap usage: 5 allocs, 4 frees, 6,528 bytes
allocated
==45177==
==45177== LEAK SUMMARY:
==45177== definitely lost: 0 bytes in 0 blocks
==45177== indirectly lost: 0 bytes in 0 blocks
==45177== possibly lost: 0 bytes in 0 blocks
==45177== still reachable: 472 bytes in 1 blocks
==45177== suppressed: 0 bytes in 0 blocks
==45177== Rerun with --leak-check=full to see details of leaked
memory
==45177==
==45177== For lists of detected and suppressed errors, rerun
with: -s
==45177== ERROR SUMMARY: 0 errors from 0 contexts (suppressed:
0 from 0)

* Thanks that, I found a minor defect in parse_tiff() for unsigned
integer,
which is, in fact, the whole patch I made. From user point of
view,
dcraw reports, in friendly way, that a file is corrupted and
returns a fail.

***@dell:/tmp/dcraw/dcraw$ valgrind ./dcraw /tmp/leak
==46346== Memcheck, a memory error detector
==46346== Copyright (C) 2002-2022, and GNU GPL'd, by Julian
Seward et al.
==46346== Using Valgrind-3.19.0 and LibVEX; rerun with -h for
copyright info
==46346== Command: ./dcraw /tmp/leak
==46346==
/tmp/leak: Unexpected end of file
==46346==
==46346== HEAP SUMMARY:
==46346== in use at exit: 0 bytes in 0 blocks
==46346== total heap usage: 3 allocs, 3 frees, 5,032 bytes
allocated
==46346==
==46346== All heap blocks were freed -- no leaks are possible
==46346==
==46346== For lists of detected and suppressed errors, rerun
with: -s
==46346== ERROR SUMMARY: 0 errors from 0 contexts (suppressed:
0 from 0)

* dcraw is written in style of '90. From a current perspective,
there could be
strangle language constructions, yet unattainable in
functionality.
Don't use dcraw, if you are paranoid. Generally, memory leaks
are present
in any software, often via shared libraries. A memory leak does
not mean
a vulnerability. Don't use any software, if you are afraid of
memory leaks.

* For Debian's package, I expect that all the patches has been
applied.
Both the runtime errors `dcraw.c:315:17' and `dcraw.c:313:49'
corresponds
to the original, the unpatched variant.

Best regards,
FH
--
F. Hroch <***@physics.muni.cz>, Masaryk University,
Dept. of theor. physics and astrophysics, Brno, Moravia, CZ