[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20250424232052.GA3372@localhost.localdomain>
Date: Thu, 24 Apr 2025 23:21:47 +0000
From: Qualys Security Advisory <qsa@...lys.com>
To: Solar Designer <solar@...nwall.com>
CC: "oss-security@...ts.openwall.com" <oss-security@...ts.openwall.com>
Subject: Re: CVE-2025-0395: Buffer overflow in the GNU C
Library's assert()
Hi Solar, all,
Sorry for the late reply, and thank you very much for looking into this
and for asking all the good questions! What follows is mainly based on
scrappy notes from January, but hopefully it will still be useful.
On Sun, Apr 13, 2025 at 03:11:48AM +0200, Solar Designer wrote:
> On this system, the above triggered the bug presumably in the same way
> Qualys had observed (segfault instead of abort) only after I changed 32
> to 64, so with page counts in the range of 32 to 63. Yet a similar page
> count (44 in gdb examples above) works very differently in my standalone
> test. I don't know why the difference.
There are probably two reasons that can explain all these differences:
1/ Difference between our command-line POC loop and a self-contained C
program: on the command line, the kernel limits the size of an argument
(including argv[0] and hence __progname) to 128KB, so anything larger
than 32 pages will result in an exec failure (Argument list too long)
and will break out of the POC loop; but not because of a segmentation
fault. In a C program that sets __progname manually, there is no such
size limit.
2/ Differences between distributions: depending on the number, size,
alignment (2MB versus 4KB) of the loaded shared libraries, plus ASLR,
the mmap space can contain holes of various sizes (random sizes, really)
which in turn can vary the nature of the memory mapping that follows the
overflowed buffer. If it is followed by a read-only mapping, it results
in a segmentation fault; if followed by an mmapped chunk, it results in
an abort from free(); if followed by a writable mapping, it results in
an abort from the original assert(); etc.
> More importantly, can those fixed 4 bytes (or 3 or 2 or 1 of them) cause
> such malloc metadata corruption that it'd be exploitable? This may also
> be affected by what original values are overwritten by those, which
> could vary due to ASLR. I haven't looked into that. Maybe Qualys will?
The only exploitation opportunity that exists after the buffer overflow
seems to be the call to "free (str);", so we have to distinguish three
cases:
a/ The target is a SUID program on a little-endian system, and "str" is
an mmapped chunk that immediately follows the overflowed buffer: the 1-4
bytes that overflow the buffer only allow us to corrupt the prev_size of
the "str" chunk, not its size (which also contains its IS_MMAPPED bit),
so "free (str);" will always call munmap_chunk(). And because we do not
control the 1-4 bytes that overflow the buffer ("d.\n"), we cannot pass
the alignment checks in munmap_chunk() (on a little-endian system), so
we believe that this case is not exploitable.
b/ The target is a SUID program on a big-endian system, and "str" is an
mmapped chunk that immediately follows the overflowed buffer: this case
is similar to a/, but it may be possible to pass the alignment checks in
munmap_chunk() (on a big-endian system). We have not investigated this
case any further.
c/ The target is a multithreaded SUID program on a little-endian system,
and "str" is mallocated in the thread's heap that immediately follows
the overflowed buffer: the 1-4 bytes that overflow the buffer allow us
to corrupt the first field of this heap_info, ar_ptr, and this corrupt
ar_ptr may then point into our own data in the thread's heap, which in
turn may allow us to control various fields of the malloc_state during
the call to "free (str);". This case may very well be exploitable, but
we have not investigated it further for now because we do not know any
multithreaded SUID program that contains a reachable assertion failure.
Thanks again, and hopefully this helps! With best regards,
--
the Qualys Security Advisory team
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
