On 10/12/22 22:39, Georgi Guninski wrote:
On Fri, Sep 16, 2022 at 6:44 AM Matthew Fernandez <matthew.fernandez@xxxxxxxxx> wrote:What is the security boundary being violated here? As a maintainer of some of the packages implicated here, I’m unsure what my actionable tasks are. The threat model(s) for my packages does not consider crashes to be a security violation. On the other side, things like crypto code frequently use their own non-GMP implementation of bignum arith for this (and other) reason.Observe that ubuntu issue advisory about libgmp crash without mentioning potential exploitability. quote: https://ubuntu.com/security/notices/USN-5672-1 Details 12 October 2022 It was discovered that GMP did not properly manage memory on 32-bit platforms when processing a specially crafted input. An attacker could possibly use this issue to cause applications using GMP to crash, resulting in a denial of service. References CVE-2021-43618
I am not quite sure what point you’re making. CVE-2021-43618 is a different issue; a programming error that results in a segfault. I.e. even if an application using libgmp supplied their own allocator,¹ they could still experience segfaults when dealing with malicious input.
The case you brought to FD (IIUC) is an input including large numbers that causes libgmp to exhaust memory when dealing with them. In this case, an application supplying their own allocator should be able to detect and survive this scenario. So again, I don’t see what security boundary is being violated here.
¹ The libgmp API docs describe how to do this, https://gmplib.org/manual/Custom-Allocation. “By default GMP uses malloc, realloc and free for memory allocation, and if they fail GMP prints a message to the standard error output and terminates the program. Alternate functions can be specified, to allocate memory in a different way or to have a different error action on running out of memory.” _______________________________________________ Sent through the Full Disclosure mailing list https://nmap.org/mailman/listinfo/fulldisclosure Web Archives & RSS: https://seclists.org/fulldisclosure/