Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Null pointer dereference at cli/wvunpack.c #121

Closed
xiaoxiaoafeifei opened this issue Jul 5, 2022 · 1 comment · May be fixed by #122
Closed

Null pointer dereference at cli/wvunpack.c #121

xiaoxiaoafeifei opened this issue Jul 5, 2022 · 1 comment · May be fixed by #122

Comments

@xiaoxiaoafeifei
Copy link

xiaoxiaoafeifei commented Jul 5, 2022

Hi, I found a null pointer dereference at cli/wvunpack.c:911

Here's ASAN log:
AddressSanitizer:DEADLYSIGNAL

==84257==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x561b47a970c6 bp 0x7fff13952fb0 sp 0x7fff1394fca0 T0)
==84257==The signal is caused by a WRITE memory access.
==84257==Hint: address points to the zero page.
#0 0x561b47a970c5 in main cli/wvunpack.c:911
#1 0x7efc4f5c0082 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x24082)
#2 0x561b47a945ed in _start (/usr/local/bin/wvunpack+0xa5ed)
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV cli/wvunpack.c:911 in main
==84257==ABORTING

Steps to Reproduce
./configure --disable-shared CFLAGS="-fsanitize=address -ggdb" CXXFLAGS="-fsanitize=address -ggdb"
make & make install
/usr/local/bin/wvunpack -m poc.wv -o /

poc.ZIP

@xiaoxiaoafeifei xiaoxiaoafeifei changed the title null pointer dereference at cli/wvunpack.c Null pointer dereference at cli/wvunpack.c Jul 5, 2022
dbry added a commit that referenced this issue Jul 6, 2022
* check for NULL pointer before dereferencing in wvunpack.c
* sanitize custom extensions to be alphanumeric only
@dbry
Copy link
Owner

dbry commented Jul 6, 2022

Hi, and thanks for reporting this. It's quite a catch!

I have pushed a fix for it. Please let me know if you run into any more.

BTW, I don't consider this to be particularly worrisome from a security standpoint. It requires the command-line program (which are not standard in any repo) and it requires both a crafted WavPack file and a crafted command line. Further, all it can cause is an exception (i.e., no code injection).

Nevertheless, I'm glad I was able to fix it before my imminent release!

@dbry dbry closed this as completed Mar 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants