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 <http://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 list
debian-astro-maintain...@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-astro-maintainers
