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 <deb...@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@alioth-lists.debian.nethttps://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-astro-maintainers > > >
