VLC versions before 2.1.5 contain a vulnerability in the transcode module that may allow a corrupted stream to overflow buffers on the heap. With a non-malicious input, this could lead to heap corruption and a crash. However, under the right circumstances, a malicious attacker could potentially use this vulnerability to hijack program execution, and on some platforms, execute arbitrary code.
This vulnerability was found by fuzzing using CERT’s Basic Fuzzing Framework (BFF) and a sample file from mplayerhq. Testing was initially performed on Debian Sid (x86) using the VLC version 2.1.2-2+b3 from Debian, and later on Windows XP 32-bit using VLC version 2.1.3 from upstream.
After some time, BFF produced a fuzzed file that caused the following crash:
*** Error in `/usr/bin/vlc': free(): corrupted unsorted chunks: 0xb384fd68 *** ======= Backtrace: ========= /lib/i386-linux-gnu/i686/cmov/libc.so.6(+0x75e52)[0xb756be52] /lib/i386-linux-gnu/i686/cmov/libc.so.6(+0x76b90)[0xb756cb90] /usr/lib/libvlccore.so.7(+0x7df4b)[0xb7481f4b] /usr/lib/vlc/plugins/audio_filter/libmpgatofixed32_plugin.so(+0xb5a)[0xb3466b5a] /usr/lib/libvlccore.so.7(aout_FiltersPlay+0x131)[0xb7477021] /usr/lib/vlc/plugins/stream_out/libstream_out_transcode_plugin.so(+0x579a)[0xb47a979a] /usr/lib/vlc/plugins/stream_out/libstream_out_transcode_plugin.so(+0x20f8)[0xb47a60f8] /usr/lib/libvlccore.so.7(+0xa3ce1)[0xb74a7ce1] /usr/lib/libvlccore.so.7(+0x3a0bf)[0xb743e0bf] /lib/i386-linux-gnu/i686/cmov/libpthread.so.0(+0x6cf1)[0xb76b2cf1] /lib/i386-linux-gnu/i686/cmov/libc.so.6(clone+0x5e)[0xb75e5c3e]
Further investigation narrowed the issue to two functions in
In the function
Convert, this code allocates heap space based on the number of samples,
bits, and channels detected:
1 2 3 4 5
However, in the function
DoWork, the samples and channels are detected using
a different method:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37
With a sufficiently corrupted input stream, this allows for a situation where the buffer is allocated to contain one channel of data, but then two channels of data are written to it, causing the write to overflow the buffer.
Prior to being notified of this issue, the VLC team had already made changes to the 2.2 development branch here, here, and here that corrects this issue by reinitilizing the filters when a format change is detected. However, the fixes had not yet been backported to the 2.1 maintenance branch.
Once notified, the VLC team quickly resolved the issue by backporting the relevant patches to the maintenance branch here, here, and here. They also added an additional check on both the development and maintenance branches for good measure.
CVE-2014-6440 was assigned to this issue.
2014-04-18: VLC team notified of issue
2014-04-19: Fixed in VLC repository
2014-07-06: VLC 2.1.5 maintenance release