Debian has issued an advisory on November 23: https://www.debian.org/security/2018/dsa-4343 The issue was fixed upstream in 2018.10.17. An additional security issue was fixed in 2018.11.26: http://live555.com/liveMedia/public/changelog.txt As it is statically compiled into mplayer and vlc, those will need to rebuilt against the updated live package.
(In reply to David Walser from comment #0) > Debian has issued an advisory on November 23: > https://www.debian.org/security/2018/dsa-4343 > > The issue was fixed upstream in 2018.10.17. An additional security issue > was fixed in 2018.11.26: > http://live555.com/liveMedia/public/changelog.txt > > As it is statically compiled into mplayer and vlc, those will need to > rebuilt against the updated live package. Assigning to all packagers collectively, since there is no registered maintainer for this package. Also CC'ing some committers and Shlomi, who maintains mplayer and vlc.
Assignee: bugsquad => pkg-bugsCC: (none) => marja11, nicolas.salguero, shlomif, smelror
Hi, I updated live to version 2018.11.26 for Mageia 6 yesterday. I did it for Cauldron a month ago. Best regards, Nico.
live-2018.11.26-1.mga6 live-devel-2018.11.26-1.mga6 from live-2018.11.26-1.mga6.src.rpm ***NOTE*** mplayer and vlc still need to rebuilt in both Mageia 6 AND Cauldron.
We should also update VLC to 3.0.5: https://www.videolan.org/developers/vlc-branch/NEWS
VLC is updated and built in Cauldron (checked into mga6 SVN). mplayer built in Cauldron core/release, but failed in tainted on vo_vdpau.c, which built just fine in core, which makes no sense. http://pkgsubmit.mageia.org/uploads/done/cauldron/core/release/20181229225526.luigiwalser.duvel.8132/mplayer-1.3.0-20.mga7/build.0.20181229230422.log http://pkgsubmit.mageia.org/uploads/failure/cauldron/tainted/release/20181230060931.luigiwalser.duvel.38242/log/mplayer-1.3.0-20.mga7.tainted/build.0.20181230061117.log
I had to switch back to a SVN snapshot of mplayer in Cauldron, so that's fixed.
I'll also update FFmpeg to 3.3.9 for Mageia 6, which fixes CVE-2018-15822. http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-15822 https://git.ffmpeg.org/gitweb/ffmpeg.git/shortlog/n3.3.9 http://ffmpeg.org/download.html http://ffmpeg.org/security.html
Note that there are core and tainted builds for this ffmpeg, mplayer, and vlc. Advisory: ======================== Updated live, ffmpeg, mplayer, and vlc packages fix security vulnerabilities: A bug in the server implementation of RTSP-over-HTTP in live could allow a denial-of-service attack. A bug in the server implementation of RTSP-over-HTTP could allow a buffer overflow, which could result in the execution of arbitrary code when parsing a malformed RTSP stream (CVE-2018-4013). The flv_write_packet function in libavformat/flvenc.c in FFmpeg through 3.3.8 does not check for an empty audio packet, leading to an assertion failure (CVE-2018-15822). The live package has been updated to version 2018.11.26, the ffmpeg package has been updated to version 3.3.9, and the vlc package has been updated to version 3.0.5, fixing these issues and other bugs. The mplayer package has been rebuilt against the update live package to fix the RTSP-over-HTTP issues in mplayer. References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-4013 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-15822 http://live555.com/liveMedia/public/changelog.txt https://www.videolan.org/developers/vlc-branch/NEWS https://www.debian.org/security/2018/dsa-4343 ======================== Updated packages in core/updates_testing: ======================== live-2018.11.26-1.mga6 live-devel-2018.11.26-1.mga6 from live-2018.11.26-1.mga6.src.rpm Updated packages in {core,tainted}/updates_testing: ======================== vlc-3.0.5-1.mga6 libvlc5-3.0.5-1.mga6 libvlccore9-3.0.5-1.mga6 libvlc-devel-3.0.5-1.mga6 vlc-plugin-common-3.0.5-1.mga6 vlc-plugin-zvbi-3.0.5-1.mga6 vlc-plugin-kate-3.0.5-1.mga6 vlc-plugin-libass-3.0.5-1.mga6 vlc-plugin-lua-3.0.5-1.mga6 vlc-plugin-ncurses-3.0.5-1.mga6 vlc-plugin-lirc-3.0.5-1.mga6 svlc-3.0.5-1.mga6 vlc-plugin-aa-3.0.5-1.mga6 vlc-plugin-sdl-3.0.5-1.mga6 vlc-plugin-shout-3.0.5-1.mga6 vlc-plugin-opengl-3.0.5-1.mga6 vlc-plugin-vdpau-3.0.5-1.mga6 vlc-plugin-projectm-3.0.5-1.mga6 vlc-plugin-theora-3.0.5-1.mga6 vlc-plugin-twolame-3.0.5-1.mga6 vlc-plugin-fluidsynth-3.0.5-1.mga6 vlc-plugin-gme-3.0.5-1.mga6 vlc-plugin-schroedinger-3.0.5-1.mga6 vlc-plugin-speex-3.0.5-1.mga6 vlc-plugin-flac-3.0.5-1.mga6 vlc-plugin-dv-3.0.5-1.mga6 vlc-plugin-mod-3.0.5-1.mga6 vlc-plugin-mpc-3.0.5-1.mga6 vlc-plugin-sid-3.0.5-1.mga6 vlc-plugin-pulse-3.0.5-1.mga6 vlc-plugin-jack-3.0.5-1.mga6 vlc-plugin-upnp-3.0.5-1.mga6 vlc-plugin-gnutls-3.0.5-1.mga6 vlc-plugin-libnotify-3.0.5-1.mga6 vlc-plugin-chromaprint-3.0.5-1.mga6 ffmpeg-3.3.9-1.mga6 libavcodec57-3.3.9-1.mga6 libpostproc54-3.3.9-1.mga6 libavformat57-3.3.9-1.mga6 libavutil55-3.3.9-1.mga6 libavresample3-3.3.9-1.mga6 libswscaler4-3.3.9-1.mga6 libavfilter6-3.3.9-1.mga6 libswresample2-3.3.9-1.mga6 libffmpeg-devel-3.3.9-1.mga6 libffmpeg-static-devel-3.3.9-1.mga6 mplayer-1.3.0-13.mga6 mplayer-doc-1.3.0-13.mga6 mplayer-gui-1.3.0-13.mga6 mencoder-1.3.0-13.mga6 from SRPMS: vlc-3.0.5-1.mga6.src.rpm ffmpeg-3.3.9-1.mga6.src.rpm mplayer-1.3.0-13.mga6.src.rpm
Source RPM: live, mplayer, vlc => live, ffmpeg, mplayer, vlcSummary: live555 new security issues CVE-2018-4013 and other DoS issue => live555 new security issues CVE-2018-4013 and other DoS issue, ffmpeg new security issue CVE-2018-15822, VLC 3.0.5Assignee: pkg-bugs => qa-bugs
Help needed here. Decided to tackle this because vlc, mplayer and ffmpeg are used a lot here. However I do not understand the concept of "streaming". It does not seem to be the same thing as the client-server paradigm. live555 is running from the command line on a host with address 192.168.1.<aaa> $ live555MediaServer LIVE555 Media Server version 0.88 (LIVE555 Streaming Media library version 2016.01.24). Play streams from this server using the URL rtsp://192.168.1.aaa:8554/<filename> Using $ vlc rtsp://192.168.1.aaa:8554/ADifferentSun.mkv launches the video locally. Fair enough. It does not work on another host though, either using the same command or running vlc and using the network access section to specify the url.
CC: (none) => tarazed25
Make sure your local firewall isn't blocking another machine from connecting to it.
Note that Jóse is rebuilding vlc as vlc-3.0.5-2.mga6 right now (he forgot to use a subrel) to fix a minor issue.
CC: (none) => lists.jjorge
Blocks: (none) => 21145
@David, re comment 11. Not a problem at present because I am still at the pre-update stage.
@David, re comment 10. That prompted me to open 8554/tcp and 8554/udp. /etc/services lists rtsp-alt against 8554/tcp|udp. No progress. I can only guess that vlc needs some kind of configuration on the remote host.
I could test mpv and vlc playing my French ISP rtsp TV. I could also convert with ffmpeg some files. All ok!
Status: NEW => ASSIGNEDWhiteboard: (none) => MGA6-64-OK
@José Thank you for your 'OK'. "Jóse is rebuilding vlc as vlc-3.0.5-2.mga6". Could you please confirm the versions of: vlc- ffmpeg- mplayer- that you tried, to get the advisory right. Are they the same in 'core' and 'tainted'? TIA Lewis
CC: (none) => lewyssmith
(In reply to Lewis Smith from comment #15) > Could you please confirm the versions of: > vlc- > ffmpeg- > mplayer- > that you tried, to get the advisory right. Are they the same in 'core' and > 'tainted'? > Sorry, I only tested tainted versions. They are the versions in the comment 8 except the 3.0.5-2 for vlc.
I wonder what is going on? Just now I tried the rtsp URL in vlc on the remote machine and it immediately connected and started playing the specified video. ??? The only difference was that I used 'difda' to denote the server address rather than the full network address.
Enabled tainted updates testing and updated the database. Installed 50 packages. Started the live555 mediaserver. Moved to another machine and started vlc playing a stream from the server host. No problem. One of the fixed issues affects streaming rtsp over http using live555. Not competent to test that - what does it mean for a start? In the absence of any test for that we shall simply have to accept that everything is OK. Used ffmpeg to convert an m2t file to mkv format. That took a while at a speed o about 8.5x. The sesulting file could be played by vlc but the subtitles had vanished - because I had not specified them on the command line. Used gmplayer to select an mp4 video and play that. Ran $ vlc --avcodec-hw none MortallyWounded.m2t That played fine, with subtitles Tainted looks good for 64-bits. $ rpm -qa | egrep 'vlc|ffmpeg|mplayer' lib64vlc5-3.0.5-2.mga6.tainted ffmpeg-3.3.9-1.mga6.tainted mplayer-1.3.0-13.mga6.tainted Going to attempt to switch to core versions.
Therein lies a problem. Referencing comment 18. Disabled tainted updates testing and enabled core updates testing. Updated database. MageiaUpdate could not see any of the packages. Trying individual urpmi commands yields this: A requested package cannot be installed: vlc-3.0.5-2.mga6.x86_64 (in order to keep vlc-3.0.5-2.mga6.tainted.x86_64) $ urpme vlc Gets rid of the tainted version but leaves a stack of orphaned plugins.# urpmi --searchmedia "Core Updates Testing" vlc To satisfy dependencies, the following packages are going to be installed: Package Version Release Arch (medium "Core Updates Testing") vlc 3.0.5 2.mga6 x86_64 vlc-plugin-common 3.0.5 2.mga6 x86_64 vlc-plugin-lua 3.0.5 2.mga6 x86_64 (recommended) vlc-plugin-theora 3.0.5 2.mga6 x86_64 (recommended) vlc-plugin-vdpau 3.0.5 2.mga6 x86_64 So far so good but that still leaves a lot of packages to be installed manually. Leaving this until tomorrow.
In the future, test core first. Urpmi will update those to tainted, but not the other way around.
Operation downgrade completed - not easy. Upgraded from core updates testing without any trouble but on examination find that the core versions have been bumped, e.g. $ rpm -qa | grep vlc vlc-plugin-aa-3.0.5-2.mga6 vlc-plugin-opengl-3.0.5-2.mga6 vlc-plugin-flac-3.0.5-2.mga6 vlc-plugin-schroedinger-3.0.5-2.mga6 lib64vlc5-3.0.5-2.mga6 vlc-plugin-shout-3.0.5-2.mga6 vlc-plugin-kate-3.0.5-2.mga6 vlc-plugin-common-3.0.5-2.mga6 vlc-plugin-pulse-3.0.5-2.mga6 vlc-plugin-ncurses-3.0.5-2.mga6 vlc-3.0.5-2.mga6 lib64vlccore9-3.0.5-2.mga6 vlc-plugin-gme-3.0.5-2.mga6 vlc-plugin-lua-3.0.5-2.mga6 npapi-vlc-2.2.0-1.mga6 vlc-plugin-mod-3.0.5-2.mga6 vlc-plugin-fluidsynth-3.0.5-2.mga6 vlc-plugin-zvbi-3.0.5-2.mga6 lib64vlc-devel-3.0.5-2.mga6 vlc-plugin-twolame-3.0.5-2.mga6 vlc-plugin-libass-3.0.5-2.mga6 vlc-plugin-projectm-3.0.5-2.mga6 vlc-plugin-sid-3.0.5-2.mga6 svlc-3.0.5-2.mga6 vlc-plugin-chromaprint-3.0.5-2.mga6 vlc-plugin-libnotify-3.0.5-2.mga6 vlc-plugin-jack-3.0.5-2.mga6 vlc-plugin-sdl-3.0.5-2.mga6 vlc-plugin-vdpau-3.0.5-2.mga6 vlc-plugin-lirc-3.0.5-2.mga6 vlc-plugin-gnutls-3.0.5-2.mga6 vlc-plugin-speex-3.0.5-2.mga6 vlc-plugin-mpc-3.0.5-2.mga6 vlc-plugin-dv-3.0.5-2.mga6 vlc-plugin-upnp-3.0.5-2.mga6 vlc-plugin-theora-3.0.5-2.mga6 Is that to be expected?
(In reply to Len Lawrence from comment #21) > Operation downgrade completed - not easy. > Upgraded from core updates testing without any trouble but on examination > find that the core versions have been bumped, e.g. > $ rpm -qa | grep vlc > vlc-plugin-aa-3.0.5-2.mga6 > Is that to be expected? Yes, the bump in release was for both core and tainted. They fix some file paths so that now under Plasma when inserting a DVD vlc appears again in the suggested players.
Thanks José; had just confirmed it by checking distrib-coffee.
Advisory from comments 8 & 16. I think after all Len's work, this can be validated also. BUT I leave that to Len if you pick[ed] at the 'core' version of something; please do.
Keywords: (none) => advisory
Repeating the tests, command-line only. lib555 media server launched, streamed video playing with vlc on another machine on the network. vlc working with various formats: A .mov file showed GL 30FPS, BLIT VSYNC ON on screen. A .m2t file displayed the embedded subtitles OK when requested, which is an advance on the previous tests with tainted. tainted needed '--avcodec-hw none' to display subtitles and remove the continuous stream of hardware errors. The core version now shows only: [0000000001f822a0] skins2 interface: skin: ASkin for VLC 0.8.6 author: Anton [0000000001f822a0] skins2 interface error: pls, check bitmap sizes for id: Play Button [...] Repeat Playlist [00007f9e6cc040a0] main decoder error: buffer deadlock prevented [00007f9e6cc040a0] avcodec decoder: Using NVIDIA VDPAU Driver Shared Library 410.78 Sat Nov 10 22:05:34 CST 2018 for hardware decoding [00007f9e6cc040a0] avcodec decoder error: hardware acceleration picture allocation failed These errors do not appear to be significant. The chosen skin displays nicely. A Blender 4K UHD webm movie played OK at 24 FPS, fullscreen on a 4K monitor, with just an occasional vertical ripple (horizontal linear aberration). Inserted a commercial DVD and played that OK at 30 FPS. Sound on Analogue Stereo. Played Handel WAV file - codec PCM S16 LE. Checked flac, perfect reproduction of some Elizabethan music. It identified the original disc, which mediainfo -f does not. ogg and mp3 codecs work with vlc. Ran mplayer gui from the command-line: $ mplayer -gui Installed the mplayer skins in /usr/share/mplayer/skins and opened the skin browser to choose "phony". Pressing the DVD button started the commercial DVD OK. Subtitles displayed automatically. Played with the play buttons, skipping sections, fast forward, pause and resume. Tried setting up a playlist, clicked OK (without selecting an entry) and mplayer crashed. Continued trying to work with the gui but had to give up - its behaviour is not consistent and it is too easy to crash and audio sometimes does not work but that is probably down to the lack of free codecs. Playing fine from the cli. Toggle fullscreen with the F key. ogg works, as does flac, mp3 and wav. Used ffmpeg to convert an MP4 file to Matroska format then an M4V file to an AVI video. Worked fine, played in vlc. Used a local ruby script to run ffmpeg to combine a video.mp4 file with its corresponding .srt file to embed subtitles. That worked fine. The effective command was: $ ffmpeg -n -i #{video} -f srt -i #{subtitles} -c:s mov_text -metadata:s:s:0 language=eng -c:v copy -c:a copy #{temp} It looks like these core updates are working for 64-bits. One thing not tested is rtsp over http in live555.
Re comment 24: Thanks Lewis, validating this then.
Keywords: (none) => validated_updateCC: (none) => sysadmin-bugs
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2019-0029.html
Resolution: (none) => FIXEDStatus: ASSIGNED => RESOLVED
This update also fixed CVE-2018-19857 in VLC: https://www.debian.org/security/2019/dsa-4366 https://security-tracker.debian.org/tracker/CVE-2018-19857
The DoS issue in live: "A bug in the server implementation of RTSP-over-HTTP in live could allow a denial-of-service attack." is CVE-2019-6256. openSUSE has issued an advisory for this on January 18: https://lists.opensuse.org/opensuse-updates/2019-01/msg00064.html
Summary: live555 new security issues CVE-2018-4013 and other DoS issue, ffmpeg new security issue CVE-2018-15822, VLC 3.0.5 => live555 new security issues CVE-2018-4013 and CVE-2019-6256, ffmpeg new security issue CVE-2018-15822, VLC 3.0.5