Heap-buffer-overflow in src/flac.c:274:41 in flac_buffer_copy

[yuawn]

Hi, I found a vulnerability in current master 34bd39b.

There is a heap-buffer-overflow in src/flac.c:274:41 in flac_buffer_copy.

The vulnerability can lead to heap-based buffer overflow via a crafted sound file, and potentially control heap data by forge buffer content to perform heap exploitation.

To reproduce on x86-64 Ubuntu 20.04.2 with clang-11:

export CC=clang-11
export CFLAGS='-g -fsanitize=address'

cd libsndfile
./autogen.sh
mkdir build
cd build
../configure --disable-shared
make

./programs/sndfile-convert ./heap_overflow_poc ./out.wav

PoC: heap_overflow_poc.gz

ASAN report:

=================================================================
==3712127==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x621000001310 at pc 0x00000054e793 bp 0x7ffe0d1368b0 sp 0x7ffe0d1368a8
READ of size 4 at 0x621000001310 thread T0
    #0 0x54e792 in flac_buffer_copy /home/yuawn/fuzz-targets/libsndfile/master/libsndfile/build/../src/flac.c:274:41
    #1 0x54fc83 in flac_read_loop /home/yuawn/fuzz-targets/libsndfile/master/libsndfile/build/../src/flac.c:946:3
    #2 0x549be9 in flac_read_flac2i /home/yuawn/fuzz-targets/libsndfile/master/libsndfile/build/../src/flac.c:997:13
    #3 0x512fb4 in sf_readf_int /home/yuawn/fuzz-targets/libsndfile/master/libsndfile/build/../src/sndfile.c:1946:10
    #4 0x4ffae5 in sfe_copy_data_int /home/yuawn/fuzz-targets/libsndfile/master/libsndfile/build/../programs/common.c:94:22
    #5 0x4fee78 in main /home/yuawn/fuzz-targets/libsndfile/master/libsndfile/build/../programs/sndfile-convert.c:367:3
    #6 0x7f1f78add0b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)
    #7 0x41fd9d in _start (/home/yuawn/fuzz-targets/libsndfile/master/libsndfile/build/programs/sndfile-convert+0x41fd9d)

0x621000001310 is located 0 bytes to the right of 4624-byte region [0x621000000100,0x621000001310)
allocated by thread T0 here:
    #0 0x4c5d8f in __interceptor_malloc /home/yuawn/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:145:3
    #1 0x7f1f79089b47  (/lib/x86_64-linux-gnu/libFLAC.so.8+0x22b47)

SUMMARY: AddressSanitizer: heap-buffer-overflow /home/yuawn/fuzz-targets/libsndfile/master/libsndfile/build/../src/flac.c:274:41 in flac_buffer_copy
Shadow bytes around the buggy address:
  0x0c427fff8210: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c427fff8220: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c427fff8230: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c427fff8240: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c427fff8250: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0c427fff8260: 00 00[fa]fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c427fff8270: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c427fff8280: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c427fff8290: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c427fff82a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c427fff82b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
  Shadow gap:              cc
==3712127==ABORTING

[evpobr]

@yuawn , thanks for report. Can you help to fix it?

[yuawn]

@evpobr
When i=0, j=0, channels=1, offset=0, pflac->bufferpos=1152, frame->header.blocksize=32768 at

retpcm [offset + j] = ((uint32_t) buffer [j][pflac->bufferpos]) << shift ;

ASAN triggered

The frame->header.blocksize / 4 is larger than the (uint32_t*)buffer size, because it reuse the buffer for header.blocksize=1152.

What do you think about it need to request larger size or it is not make a sense that frame->header.blocksize become larger.

[evpobr]

I can't figure it out yet.

[yuawn]

@evpobr
I add the code #732 to check whether frame->header.blocksize is larger than allocated size of buffer to prevent buffer be improper reuse and cause heap-buffer-overflow.

[yuawn]

Hi @evpobr @arthurt,

I reproduced the vulnerability on the old released version 1.0.28, the older version is too old that I can't compile it with ASAN.
At least this bug affects >= 1.0.28 to the latest released version 1.0.31, and even affects current master.

This vulnerability exists in the shared library, not binary, and it is easy to be exploited because the overflow length and content of the buffer can be easily controlled by the crafted sound file.

It should be fixed as soon as possible, Thanks!

[evpobr]

Thanks to you for your help. We will merge it soon.

[tcullum-rh]

@yuawn could you please elaborate on:

The vulnerability can lead to heap-based buffer overflow via a crafted sound file, and potentially control heap data by forge buffer content to perform heap exploitation.

1. When you use the term "heap-based buffer overflow" are you referring to a buffer overREAD or a WRITE?
2. ASAN shows this as an out-of-bounds READ of 4 bytes
3. What type of heap exploitation are you referring to? I am not intimately familiar with libsndfile, but this seems to be a case where data is overread from buffer (pflac->wbuffer), bitshifted left, and then stored in retpcm (which essentially points to psf->codec_data->ptr). I'm not sure all of what data pointed to by that pointer is used for, but at this point it seems it's just an out-of-bounds read storing data in the flac blob.

Am I missing something?

[yuawn]

Hi @tcullum-rh,

1. buffer over-read
2. It can be more since the vulnerable code is in the loop and the number of iteration is attacker-controlled
3. I want to summarize that the bug can be used to leak information and defeat ASLR by reading out-of-bounds on heap segment, and then could be combined with heap exploitation techniques (e.g., Forging chunks, T-cache dup, fastbin attack ...).

I hope I answered your question, thank you!

[tcullum-rh]

This issue is now CVE-2021-4156.

[evpobr]

@tcullum-rh , thanks.