<div dir="auto"><p dir="ltr"> Hi,</p>
<p dir="ltr">I understand your concerns. Here is the CVE number: 1775652</p></div>
<br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 22 Nov, 2024, 6:00 am Thorsten Alteholz, <<a href="mailto:debian@alteholz.de" rel="noreferrer noreferrer" target="_blank">debian@alteholz.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
On Fri, 22 Nov 2024, Ajin Deepak wrote:<br>
> To address your first question, in the context of *dcraw*, a denial of<br>
> service (DoS) vulnerability refers to the software's inability to handle<br>
> malformed files appropriately. A specially crafted file can cause the<br>
> application to crash, disrupting its functionality for users relying on it<br>
> for image processing. While it is not a networked "service," this still<br>
> constitutes a DoS as it prevents the intended use of the tool.<br>
<br>
this sounds like the definition of a mere bug. I have never seen this <br>
being called a DoS. Whatever, if you like to call it this way ...<br>
<br>
> Additionally, the issue highlighted here involves a memory leak. This leak<br>
> exposes memory addresses that could assist in exploiting other<br>
> vulnerabilities, such as buffer overflows.<br>
<br>
So what? Even if you are able to execute some code, you can only get <br>
information from one user of the system. Back to the beginning of this <br>
discussion: this looks like just an unimportant or minor issue and is far <br>
away from the overhyped critical issue that you wanted to create in your <br>
first mail.<br>
Anybody who processes files from unknown sources of the internet has a <br>
share of the blame in case bad things happen.<br>
<br>
> Apologies for the confusion earlier regarding multi-user systems—I was<br>
> referring to scenarios involving privilege escalation. Tools installed by<br>
> the root user often have elevated privileges or capabilities, especially if<br>
> they run with *setuid* permissions or interact with privileged system<br>
> components. If such a tool has vulnerabilities and is executed by a<br>
> non-privileged user, exploiting it could escalate the attacker's privileges<br>
> to root or other users, as in the scenarios you mentioned.<br>
<br>
Sure but this isn't related to dcraw, is it?<br>
<br>
> webpage .However, even if such cases are not immediately exploitable,<br>
> patching these issues is essential. Left unaddressed, they could<br>
> potentially aid exploitation when combined with other vulnerabilities in a<br>
> chain.<br>
<br>
No it is by far not essential. Applying a patch always involves the danger <br>
of introducing a regression. It is by far worse to not be able to process <br>
an image with dcraw at all than to have no fix for a fictional security <br>
issue.<br>
<br>
> And yes I did apply for CVE after your reply.<br>
<br>
Great, please share the number.<br>
<br>
   Thorsten</blockquote></div>