Uncontrolled Memory Allocation in function lodepng_realloc in hpjansson/chafa

Valid

Reported on

Jul 1st 2022


Description

Uncontrolled Memory Allocation in function lodepng_realloc at lodepng/lodepng.c:86

Version

git log
commit 06bb36ae2c9b9074e9736a2e25845a2e789cc4e6 (HEAD -> master, origin/master, origin/HEAD)
Author: Hans Petter Jansson <hpj@hpjansson.org>
Date:   Fri Jul 1 01:06:00 2022 +0200

POC

./tools/chafa/chafa --animate=off ./poc_ucma1_s.dat
=================================================================
==341557==ERROR: AddressSanitizer: requested allocation size 0x24486c909c785430 (0x24486c909c786430 after adjustments for alignment, red zones etc.) exceeds maximum supported size of 0x10000000000 (thread T0)
    #0 0x49b949 in realloc (/home/fuzz/fuzz/chafa/tools/chafa/chafa+0x49b949)
    #1 0x5e8c2d in lodepng_realloc /home/fuzz/fuzz/chafa/lodepng/lodepng.c:86:10
    #2 0x61171e in ucvector_reserve /home/fuzz/fuzz/chafa/lodepng/lodepng.c:277:18
    #3 0x6115e6 in ucvector_resize /home/fuzz/fuzz/chafa/lodepng/lodepng.c:290:10
    #4 0x61a2c3 in zlib_decompress /home/fuzz/fuzz/chafa/lodepng/lodepng.c:2239:7
    #5 0x60bcb9 in decodeGeneric /home/fuzz/fuzz/chafa/lodepng/lodepng.c:4978:20
    #6 0x607a71 in lodepng_decode /home/fuzz/fuzz/chafa/lodepng/lodepng.c:4999:3
    #7 0x60c91a in lodepng_decode_memory /home/fuzz/fuzz/chafa/lodepng/lodepng.c:5044:11
    #8 0x60cb97 in lodepng_decode32 /home/fuzz/fuzz/chafa/lodepng/lodepng.c:5050:10
    #9 0x4ebf76 in png_loader_new_from_mapping /home/fuzz/fuzz/chafa/tools/chafa/png-loader.c:74:23
    #10 0x4ead9b in media_loader_new /home/fuzz/fuzz/chafa/tools/chafa/media-loader.c:216:30
    #11 0x4da682 in run_generic /home/fuzz/fuzz/chafa/tools/chafa/chafa.c:1926:20
    #12 0x4d9eac in run /home/fuzz/fuzz/chafa/tools/chafa/chafa.c:2106:12
    #13 0x4cf868 in run_all /home/fuzz/fuzz/chafa/tools/chafa/chafa.c:2166:18
    #14 0x4cc94f in main /home/fuzz/fuzz/chafa/tools/chafa/chafa.c:2220:11
    #15 0x7ffff67aa082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16

==341557==HINT: if you don't care about these errors you may set allocator_may_return_null=1
SUMMARY: AddressSanitizer: allocation-size-too-big (/home/fuzz/fuzz/chafa/tools/chafa/chafa+0x49b949) in realloc
==341557==ABORTING

poc_ucma1_s.dat

Impact

Allocating memory based on an untrusted size value, but does not validate or incorrectly validates the size, allowing arbitrary amounts of memory to be allocated. This vulnerability is capable of crashing software or a denial of service. In addition, the lack of memory could also prevent many other programs from successfully running on the system.

We are processing your report and will contact the hpjansson/chafa team within 24 hours. 5 months ago
We have contacted a member of the hpjansson/chafa team and are waiting to hear back 5 months ago
Hans Petter Jansson modified the Severity from High to Low 5 months ago
The researcher has received a minor penalty to their credibility for miscalculating the severity: -1
Hans Petter Jansson validated this vulnerability 5 months ago

Hi, thanks for another nice find!

I set the severity to low for the following reasons: What constitutes an acceptable resource use varies from system to system and should ideally be governed by system-level measures (ulimit, cgroups, etc). For an image library, you generally want to be able to process images up to a fairly large size, which can mean gigabytes of memory. This is already too much for some systems, so this kind of mitigation is needed anyway.

On systems with overcommit (most Unix/Linux), the memory is not physically allocated until it's written to,. Otherwise the allocator will fail, and the library appears to handle that gracefully.

Still, there clearly needs to be some kind of explicit limit. I'm going to set it to 4GiB. I'll mark this as fixed when I make the next release.

TDHX ICS Security has been awarded the disclosure bounty
The fix bounty is now up for grabs
The researcher's credibility has increased: +7
Hans Petter Jansson gave praise 5 months ago
+1 and thanks again.
The researcher's credibility has slightly increased as a result of the maintainer's thanks: +1
We have sent a fix follow up to the hpjansson/chafa team. We will try again in 7 days. 5 months ago
We have sent a second fix follow up to the hpjansson/chafa team. We will try again in 10 days. 5 months ago
We have sent a third and final fix follow up to the hpjansson/chafa team. This report is now considered stale. 4 months ago
Hans Petter Jansson marked this as fixed in 1.12.4 with commit c9a893 17 days ago
The fix bounty has been dropped
This vulnerability has been assigned a CVE
Hans Petter Jansson published this vulnerability 17 days ago
to join this conversation