lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Thu, 13 Oct 2022 08:11:44 -0700
From: Matthew Fernandez <matthew.fernandez@...il.com>
To: Georgi Guninski <gguninski@...il.com>
Cc: fulldisclosure@...lists.org
Subject: Re: [FD] over 2000 packages depend on abort()ing libgmp



On 10/12/22 22:39, Georgi Guninski wrote:
> On Fri, Sep 16, 2022 at 6:44 AM Matthew Fernandez
> <matthew.fernandez@...il.com> 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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ