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

A stack buffer overflow issue in wavpack.c #99

Open
qian-feng opened this issue Mar 12, 2021 · 1 comment
Open

A stack buffer overflow issue in wavpack.c #99

qian-feng opened this issue Mar 12, 2021 · 1 comment

Comments

@qian-feng
Copy link

Summary

A stack-based buffer overflow vulnerability exists in WavPack 5.4.0 and earlier. It is discovered by Baidu Fuzzing platform. This vulnerability allows local or remote attackers to launch a code execution or a denial of service attack.

Vulnerability Description

Wavpack does not check the length of infilename when openning it. If the file does not exist, the size of infilename could exceed 512, which will overflow the error_msg buffer.

WavPack 5.4.0/cli/utils.c:438

void error_line (char *error, ...)
{
    char error_msg [512];
    va_list argptr;
    error_msg [0] = '\r';
    va_start (argptr, error);
    vsprintf (error_msg + 1, error, argptr); \\ **********error_msg of 512 could be overflowed. **********
    va_end (argptr);
    fputs (error_msg, stderr);
    finish_line ();

WavPack 5.4.0/cli/wavpack.c:1546

else if ((infile = fopen (infilename, "rb")) == NULL) {
    error_line ("can't open file %s!", infilename);  \\*******************the length of infilename is not checked***************
    WavpackCloseFile (wpc);
    return WAVPACK_SOFT_ERROR;
}

Steps to reproduce

./wavpack AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
dbry added a commit that referenced this issue Mar 13, 2021
@dbry
Copy link
Owner

dbry commented Mar 13, 2021

Thanks! But...

First of all thank you @qian-feng for reporting this bug. Good catch! I have pushed a fix for this just now.

However I take strong exception to your statement that “this vulnerability allows local or remote attackers to launch a code execution or a denial of service attack.” How could an attacker possibly use this to launch any kind of attack?

The WavPack command-line programs are not the default application for any file type and are not supplied by default in any distro. Therefore the attacker would have to convince a user to install the command-line program and then download and run a specially crafted batch or script file, or copy and paste a huge line into a terminal window.

In other words, to exploit this vulnerability the attacker must already be able to run commands on the system, which of course means it’s not a vulnerability at all. For example, it would be far easier to just do this (on Linux) because it would not require WavPack (and I’m sure a similar trick would work on Windows):

echo “speciallycrafteddata” > do-bad-things ; chmod +x do-bad-things ; ./do-bad-things

I greatly appreciate the reporting of these bugs and I enjoy fixing them and improving my programs. However, I don’t feel that presenting this as a true threat with an exaggerated description does anyone any good, nor does it make the Internet any safer. If anything, it makes the Internet less safe because it’s a distraction that takes developer and maintainer resources away from actual vulnerabilities.

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

No branches or pull requests

2 participants