Dear developers,
I am so sorry for the incorrect information, this bug was found in the 6.2-1 version of ncurses. And I think this bug has been fixed in recent commits.
Actually I am using clang-6.0 to compile ncurses, the gcc 5.5 is just the system default compiler. I am trying to statically linking the executable, maybe I am adding the wrong options, but the default behavior is static linking.
Thanks for your reply, and I will double check it next time. Sorry for the inconvenience.
On Tue, Aug 04, 2020 at 09:26:04PM +0800, Anshunkang Zhou wrote:
Dear Developers,
I found a heap-buffer-overflow in captoinfo.c:321:12, detailed system
information and build configuration is as follows, the poc is in the mail
attachment.
## System info
Ubuntu X64, gcc (Ubuntu 5.5.0-12ubuntu1), ncurses (latest master label
What's the "5.5"?
gcc 5.5 is rather old.
v6_2_20200801)
## Configure
CFLAGS="-g -fsanitize=address" LDFLAGS="-fsanitize=address" ./configure
--enable-static
ncurses doesn't have an option "--enable-static".
By default, it configures static libraries. For your purposes, this would
be the way to configure it:
CFLAGS="-g -fsanitize=address" \
LDFLAGS="-fsanitize=address" \
./configure --without-debug --without-ada
however, normally ncurses does not free memory (among other reasons,
performance, compatibilty, etc), and memory-leak checking is a
configure option:
CFLAGS="-g -fsanitize=address" \
LDFLAGS="-fsanitize=address" \
./configure --without-debug --without-ada --disable-leaks
I tried both with Debian 9's gcc 6.3.0, and AddressSanitizer reported
no errors. The memory leaks are something to investigate (but as noted
the other day, most of its messages are incorrect).
For comparison, doing this
./configure --without-debug --without-ada --with-valgrind
and using valgrind, it reports something different:
==4909== HEAP SUMMARY:
==4909== in use at exit: 9 bytes in 1 blocks
==4909== total heap usage: 24 allocs, 23 frees, 37,433 bytes allocated
==4909==
==4909== Searching for pointers to 1 not-freed blocks
==4909== Checked 68,824 bytes
==4909==
==4909== 9 bytes in 1 blocks are still reachable in loss record 1 of 1
==4909== at 0x4C2BBAF: malloc (vg_replace_malloc.c:299)
==4909== by 0x50BC3B9: strdup (strdup.c:42)
==4909== by 0x13029A: _nc_set_writedir (write_entry.c:251)
==4909== by 0x113C3E: main (tic.c:1009)
==4909==
==4909== LEAK SUMMARY:
==4909== definitely lost: 0 bytes in 0 blocks
==4909== indirectly lost: 0 bytes in 0 blocks
==4909== possibly lost: 0 bytes in 0 blocks
==4909== still reachable: 9 bytes in 1 blocks
==4909== suppressed: 0 bytes in 0 blocks
(I've found valgrind's analysis and messages to be more reliable).
--
Thomas E. Dickey <dickey@invisible-island.net>
https://invisible-island.net
ftp://ftp.invisible-island.net