From ${URL} : In modules/codec/adpcm.c, VLC can be made to perform an out-of-bounds write with user-controlled input. The function DecodeAdpcmImaQT at adpcm.c:595 allocates a buffer which is filled with bytes from the input stream. However, it does not check that the number of channels in the input stream is less than or equal to the size of the buffer, resulting in an out-of-bounds write. The number of channels is clamped at <= 5. adpcm_ima_wav_channel_t channel[2]; ... for( i_ch = 0; i_ch < p_dec->fmt_in.audio.i_channels; i_ch++ ) { channel[i_ch].i_predictor = (int16_t)((( ( p_buffer[0] << 1 )|( p_buffer[1] >> 7 ) ))<<7); channel[i_ch].i_step_index = p_buffer[1]&0x7f; ... The mangling of the input p_buffer above and in AdpcmImaWavExpandNibble() makes this difficult to exploit, but there is a potential for remote code execution via a malicious media file. Please find attached a POC which crashes VLC[1]. The vendor has confirmed the issue has been resolved and will be fixed in VLC 2.2.4 and VLC 3.0.0. @maintainer(s): after the bump, in case we need to stabilize the package, please let us know if it is ready for the stabilization or not.
Thanks for submitting this ago; looks like the first attempt at a fix on vlc-devel was rejected, but I'll keep an eye on it. I expect stabilizing 2.2.4 should be doable, but 3.0 may be waiting on some external packages to hit stable.
@Nick The adpcm bug was fixed two days later with upstream release vlc-2.2.4 https://bugs.gentoo.org/show_bug.cgi?id=585642
... by the time I am learning to use bugzilla features: I hope to have correctly managed in the right direction blocks-depends
(In reply to Ulenrich from comment #3) > ... by the time I am learning to use bugzilla features: I hope > to have correctly managed in the right direction blocks-depends better luck next time :)
Thanks Ulenrich, yes, the new 2.2.4 release looks good. I'm testing a couple versions of FFmpeg for compatibility, but I expect it will be the same as 2.2.3 (i.e. FFmpeg < 2.9 is good, will need VLC-3.x for FFmpeg-3.x).
@Nick > need VLC-3.x for FFmpeg-3.x Yes, indeed.
Arches please test and mark stable =media-video/vlc-2.2.4 with target KEYWORDS: amd64 ~arm ppc ppc64 -sparc x86 ~x86-fbsd
CVE-2016-5108 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2016-5108): Buffer overflow in the DecodeAdpcmImaQT function in modules/codec/adpcm.c in VideoLAN VLC media player before 2.2.4 allows remote attackers to cause a denial of service (crash) or possibly execute arbitrary code via a crafted QuickTime IMA file.
Stable for PPC64.
amd64 stable
x86 stable
ppc stable. Maintainer(s), please cleanup. Security, please add it to the existing request, or file a new one.
New GLSA request filed. Cleanup PR: https://github.com/gentoo/gentoo/pull/3493 @ Proxy-Maintainer: Please ack.
This issue was resolved and addressed in GLSA 201701-39 at https://security.gentoo.org/glsa/201701-39 by GLSA coordinator Aaron Bauman (b-man).