#360 [BUG] two bugs in sox

[Han Zheng]

summary

Hello, I was testing my new fuzzer and found two bugs: a reachable assertion in rate_init, rate.c:303 and a float point exception in lsx_aiffstartwrite.

environment

sox latest commit 42b3557e13e0fe01a83465b672d89faddbe65f49,
clang 12.0.1,
Ubuntu 21.10

step to reproduce

compile sox with CC=clang, CFLAGS="-fsanitize=address -g"
run command ./sox --single-threaded @@ -t aiff /dev/null

BUG1

sox: rate.c:303: void rate_init(rate_t *, rate_shared_t *, double, double, double, double, double, rolloff_t, sox_bool, sox_bool, int, int, sox_bool): Assertion `factor > 0' failed.
Aborted

BUG2

AddressSanitizer:DEADLYSIGNAL
=================================================================
==3050061==ERROR: AddressSanitizer: FPE on unknown address 0x000000591211 (pc 0x000000591211 bp 0x7ffd7929b6b0 sp 0x7ffd7929b660 T0)
    #0 0x591211 in lsx_aiffstartwrite (/home/kdsj/workspace/fuzz/sox-aiff/sox+0x591211)
    #1 0x83e26f in open_write (/home/kdsj/workspace/fuzz/sox-aiff/sox+0x83e26f)
    #2 0x83b303 in sox_open_write (/home/kdsj/workspace/fuzz/sox-aiff/sox+0x83b303)
    #3 0x8a4ae8 in open_output_file (/home/kdsj/workspace/fuzz/sox-aiff/sox+0x8a4ae8)
    #4 0x8952e1 in process (/home/kdsj/workspace/fuzz/sox-aiff/sox+0x8952e1)
    #5 0x887e23 in main (/home/kdsj/workspace/fuzz/sox-aiff/sox+0x887e23)
    #6 0x7fac08e4afcf in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
    #7 0x7fac08e4b07c in __libc_start_main_impl ../csu/libc-start.c:409
    #8 0x408864 in _start (/home/kdsj/workspace/fuzz/sox-aiff/sox+0x408864)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: FPE (/home/kdsj/workspace/fuzz/sox-aiff/sox+0x591211) in lsx_aiffstartwrite
==3050061==ABORTING

POC

as shown in attachment poc.zip

Credit

NCNIPC of China
Hexhive

[Jan Starý]

What is the @@ in 'sox --single-threaded @@ -t aiff /dev/null' supposed to be?
Syntacticaly, that's where you nae the input file.
And whatever audio file I give there, it works.

What are the files in your zip attachment supposed to show?

[Han Zheng]

What is the @@ in 'sox --single-threaded @@ -t aiff /dev/null' supposed to be?

you're correct, @@ is the place to put the input file. This is fuzzer's argument format.

And whatever audio file I give there, it works.

did you try the file given in poc.zip? in my environment I can reproduce these two bugs via the poc file given in zip.

[Jan Starý]

Are they aiff files? They have no filename extension, but contain a COMM chunk.
Renaming them to aiff, this is what soxi has to say about the assert and the fpe example, respectively:

Input File     : 'sox-assert.aiff' (sf)
Channels       : 1073807359
Sample Rate    : nan
Precision      : 8-bit
Duration       : 00:00:  nan = 0 samples ~ nan CDDA sectors
File Size      : 4.05k
Bit Rate       : 0.00
Sample Encoding: 8-bit Signed Integer PCM
Comment        : ''

Input File     : 'sox-fpe.aiff' (sf)
Channels       : 2147483648
Sample Rate    : 4.13624e-25
Precision      : 16-bit
Duration       : 00:00:00.00 = 0 samples ~ 0 CDDA sectors
File Size      : 2.96k
Bit Rate       : 0.00
Sample Encoding: 16-bit Signed Integer PCM

Are they specificaly crafted, with bogus sample rate and number of channels etc
to trigger these exceptional cases, or am I just reading them wrong?

Anyway, testing with the latest git on macOS:

$ sox --single-threaded sox-assert.aiff -t aiff /dev/null
Assertion failed: (factor > 0), function rate_init, file rate.c, line 303.
Abort trap: 6

$ sox --single-threaded sox-fpe.aiff -t aiff /dev/null

(no error)

Testing with the current git on OpenBSD 7.2:

$ sox --single-threaded sox-assert.aiff  -t aiff /dev/null 
assertion "factor > 0" failed: file "rate.c", line 303, function "rate_init"
Abort trap (core dumped)

$ sox --single-threaded sox-fpe.aiff -t aiff /dev/null     
Floating point exception (core dumped) 

The same happens without the --single-threaded option:
is it somehow relevant to the bugs?

[Han Zheng]

Sorry for the confusion, maybe I didn't explain it clearly. As an secrurity researcher, I'm trying to develop a fuzzer and find those crafted expectational cases to validate the fuzzers' efficiency and if possible, help developers to fix those bugs (if they're considered as bugs).

Are they specificaly crafted, with bogus sample rate and number of channels etc
to trigger these exceptional cases

you're correct, it's not a valid aiff files. since the goal of fuzzer is finding crafted file to trigger an unexpected behavior (e.g. assertion or floating error), which might be exploitable by malicious user.

But I didn't dive in deep into the use scenario so not sure if it really make sense. (I mean, in some cases an fpe or reachable assertion can cause a Denial of Service but if the program is designed only for local usage, then it might not make sense. I see your program been used as an benchmark for fuzzer evaluation so I fuzz it as well.) pls ignore this issue if you think it's not a security issue.

Thanks again for your time and your validation.

[Jan Starý]

I am ignoring the fuzzer angle, my only concern is the behaviour of sox.
IMHO sox shuld just plain refuse to work with a file that claims to have
2147483648 channels or a samplerate of 4.13624e-25 ...

[Jan Starý]

fixed in https://sourceforge.net/p/sox/code/merge-requests/22/

[Martin Guy]

Confirmed in 14.4.2, 42b355 and current sox.sf.net git HEAD
Absent in Debian and sox_ng-14.5.0
sox FAIL formats: can't open input file `poc_assert_rate_init': implausibly la
rge number of channels