dbry / WavPack

WavPack encode/decode library, command-line programs, and several plugins
BSD 3-Clause "New" or "Revised" License
346 stars 65 forks source link

A stack buffer overflow issue in wavpack.c #99

Open qian-feng opened 3 years ago

qian-feng commented 3 years ago

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 commented 3 years ago

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.