VLC is not receiving security updates

[Fred Barclay]

(Apology... yes the title is a little alarmist but I can't think of a better one at the moment).
I just noticed that VLC in LMDE 2 is from the deb-multimedia repo and therefore has not been receiving security updates from the Debian team. It is on version 2.2.1, while the latest from Debian Stable is 2.2.4.
This is not a wise decision, IMHO. Currently this means that those of us on Betsy can be at risk to some of these:
https://www.videolan.org/security/sa1601.html
https://www.exploit-db.com/exploits/38706/
http://cve.mitre.org/find/index.html

Here's what my machine says:

Code: Select all

fred@<redacted> ~ $ apt policy vlc
vlc:
  Installed: 1:2.2.1-dmo3+deb8u1
  Candidate: 1:2.2.1-dmo3+deb8u1
  Version table:
 *** 1:2.2.1-dmo3+deb8u1 0
        500 http://www.deb-multimedia.org/ jessie/main amd64 Packages
        100 /var/lib/dpkg/status
     2.2.4-1~deb8u1 0
        500 http://security.debian.org/ jessie/updates/main amd64 Packages
     2.2.1-1~deb8u1 0
        500 http://mirrors.gigenet.com/debian/ jessie/main amd64 Packages

Can some one else confirm and/or weigh in?

Meanwhile, I'm off to install VLC from Stable.

EDIT: the following packages look to be affected:

Code: Select all

libvlc5
libvlccore8
vlc
vlc-data
vlc-nox
vlc-plugin-notify
vlc-plugin-pulse
libgroupsock4

All of them except libgroupsock4 are v 2.2.1 and all have (unapplied) security updates in the Debian Stable repo. libgroupsock4 seems to be solely from deb-multimedia.

[xenopeek]

That shouldn't happen, right? With the same priority, apt should install the one with the highest version regardless of origin of the currently installed package. Manually trying to install the versions from Debian results in message that those packages will be DOWNGRADED. I.e., 2.2.1 from dmo is a higher version than 2.2.4 from Debian? I'm about to turn the flame thrower on and remove dmo from the repositories configuration. Certainly after reading https://wiki.debian.org/DebianMultimedi ... ith_dmo.3F.

[DeMus]

I use SolydK, which is sort of the KDE version of LMDE, and when I type "apt policy vlc" I see this:

Code: Select all

apt policy vlc
vlc:
  Installed: 2.2.4-1~deb8u1
  Candidate: 2.2.4-1~deb8u1
  Version table:
 *** 2.2.4-1~deb8u1 0
        500 http://security.debian.org/ jessie/updates/main amd64 Packages
        100 /var/lib/dpkg/status
     2.2.1-1~deb8u1 0
        500 http://ftp.debian.org/debian/ jessie/main amd64 Packages

So, here it is updated as it should. No idea why LMDE does not do that since I don't use it.

[xenopeek]

No idea why LMDE does not do that since I don't use it.

Because there is no www.deb-multimedia.org repository in your apt policy output. Have another read of Fred's post.

[xenopeek]

On a default LMDE 2 install I find these packages installed from dmo:

Code: Select all

gstreamer0.10-ffmpeg
gstreamer1.0-libav
libaacs0
libbasicusageenvironment0
libbluray1
libchromaprint0
libdca0
libdvbpsi9
libdvdcss2
libebml4
libfdk-aac1
libgegl-0.2-0
libgroupsock4
liblivemedia42
libmjpegutils-2.1-0
libmp3lame0
libmpeg2encpp-2.1-0
libmplex2-2.1-0
librtmp1
libusageenvironment2
libx264-146
libxvidcore4
libfaac0
w64codecs

If we have an alternative for all or can do without their functionality...

[killer de bug]

That shouldn't happen, right? With the same priority, apt should install the one with the highest version regardless of origin of the currently installed package. Manually trying to install the versions from Debian results in message that those packages will be DOWNGRADED. I.e., 2.2.1 from dmo is a higher version than 2.2.4 from Debian?

Code: Select all

Version table:
 *** 1:2.2.1-dmo3+deb8u1 0
        500 http://www.deb-multimedia.org/ jessie/main amd64 Packages
     2.2.4-1~deb8u1 0
        500 http://security.debian.org/ jessie/updates/main amd64 Packages

The answer is here:

2.5.2. versioning

To distinguish between our official packages and packages from d-m.o, d-m.o adds an 'epoch' to the version number and uses a specific revision counter. This means that once you installed a version from d-m.o, package management software will always consider that version newer than the official package - even when the official package is in actual fact a newer version (but without the epoch).

[Amii_Leigh]

My current version of VLC is 2.2.1 Should I try to update it somehow? I'm using Cinnamon.Will this be an issue addressed by some future update?

[xenopeek]

All the default installed packages from dmo with the version available from Debian:

Code: Select all

PACKAGE                    DMO                               DEBIAN
-------------------------  --------------------------------  -------------------------
gstreamer0.10-ffmpeg       1:0.10.13-dmo2
gstreamer1.0-libav         1:1.4.5-dmo1                      1.4.4-2
libaacs0                   0.8.1-dmo1                        0.7.1-1+b1
libbasicusageenvironment0  2:2015.03.19-dmo1                 2014.01.13-1
libbluray1                 2:0.7.0-dmo1                      1:0.6.2-1
libchromaprint0            1.2-dmo2                          1.2-1
libdca0                    0.0.5-dmo2                        0.0.5-7
libdvbpsi9                 1.2.0-dmo1                        1.2.0-1
libdvdcss2                 1.3.0-dmo1
libebml4                   1.3.1-dmo2                        1.3.0-2+deb8u1
libfdk-aac1                1:0.1.4-dmo1
libgegl-0.2-0              1:0.2.0-dmo8                      0.2.0-7+b1
libgroupsock4              2:2015.03.19-dmo1
liblivemedia42             2:2015.03.19-dmo1
libmjpegutils-2.1-0        2:2.1.0-dmo6                      1:2.1.0+debian-3
libmp3lame0                1:3.99.5-dmo4                     3.99.5+repack1-7+deb8u1
libmpeg2encpp-2.1-0        2:2.1.0-dmo6                      1:2.1.0+debian-3
libmplex2-2.1-0            2:2.1.0-dmo6                      1:2.1.0+debian-3
librtmp1                   2:2.4~20150315.gita107cef9b-dmo1  2.4+20150115.gita107cef-1
libusageenvironment2       2:2015.03.19-dmo1
libx264-146                3:0.146.2538+git121396c-dmo1
libxvidcore4               3:1.3.3-dmo1                      2:1.3.3-1
libfaac0                   1:1.28-dmo3                       1.28-6
w64codecs                  1:20071007-dmo2

To move away from dmo, you'll have to do without the functionality provided by these packages: gstreamer0.10-ffmpeg, libdvdcss2, libfdk-aac1, libgroupsock4, liblivemedia42, libusageenvironment2, libx264-146, w64codecs. The description of each package below.

Code: Select all

Package: gstreamer0.10-ffmpeg
Description: FFmpeg plugin for GStreamer
 This GStreamer plugin supports a large number of audio and video compression
 formats through the use of the FFmpeg library. The plugin contains GStreamer
 elements for encoding 40+ formats (MPEG, DivX, MPEG4, AC3, DV, ...), decoding
 elements for decoding 90+ formats (AVI, MPEG, OGG, Matroska, ASF, ...),
 demuxing 30+ formats and colorspace conversion.

Package: libdvdcss2
Description: Simple foundation for reading DVDs - runtime libraries
 To allow applications to access some of the more advanced features of the DVD
 format.

Package: libfdk-aac1
Description: Fraunhofer FDK AAC codec library.
 Fraunhofer IIS software implementations of the open ISO MPEG audio codecs AAC,
 HE-AAC, HE-AACv2 and AAC-ELD.

Package: libgroupsock4
Description: multimedia RTSP streaming library (network interfaces and sockets)
 The live555.com streaming media code is a set of C++ libraries for multimedia
 streaming, using open standard protocols (RTP/RTCP, RTSP, SIP). These libraries
 can be used to build applications to stream, receive and process MPEG, H.263+
 or JPEG video, several audio codecs, and can easily be extended to support
 additional codecs. They can also be used to build basic RTSP (Real Time
 Streaming Protocol) or SIP (Session Initiation Protocol) clients and servers. 
 
 This package contains the groupsock library. The classes in this library
 encapsulate network interfaces and sockets. In particular, the "Groupsock"
 class encapsulates a socket for sending (and/or receiving) multicast datagrams.

Package: liblivemedia42
Description: multimedia RTSP streaming library
 The live555.com streaming media code is a set of C++ libraries for multimedia
 streaming, using open standard protocols (RTP/RTCP, RTSP, SIP). These libraries
 can be used to build applications to stream, receive and process MPEG, H.263+
 or JPEG video, several audio codecs, and can easily be extended to support
 additional codecs. They can also be used to build basic RTSP (Real Time
 Streaming Protocol) or SIP (Session Initiation Protocol) clients and servers. 
 
 This package contains the liveMedia library which defines a class hierarchy -
 rooted in the "Medium" class - for a variety of streaming media types and
 codecs.

Package: libusageenvironment2
Description: multimedia RTSP streaming library (UsageEnvironment classes)
 The live555.com streaming media code is a set of C++ libraries for multimedia
 streaming, using open standard protocols (RTP/RTCP, RTSP, SIP). These libraries
 can be used to build applications to stream, receive and process MPEG, H.263+
 or JPEG video, several audio codecs, and can easily be extended to support
 additional codecs. They can also be used to build basic RTSP (Real Time
 Streaming Protocol) or SIP (Session Initiation Protocol) clients and servers. 
 
 This package contains the UsageEnvironment library. The "UsageEnvironment" and
 "TaskScheduler" classes are used for scheduling deferred events, for assigning
 handlers for asynchronous read events, and for outputting error/warning
 messages. Also, the "HashTable" class defines the interface to a generic hash
 table, used by the rest of the code. 
 
 These are all abstract base classes; they must be subclassed for use in an
 implementation. These subclasses can exploit the particular properties of the
 environment in which the program will run - e.g., its GUI and/or scripting
 environment.

Package: libx264-146
Description: x264 video coding library
 libx264 is an advanced encoding library for creating H.264 (MPEG-4 AVC) video
 streams. 
 
 This package contains the libx264 shared library.

Package: w64codecs
Description: win64 binary codecs
 This package contain video codecs for popular proprietary formats not natively
 supported by mplayer. 
 
 Add support for RealVideo.

Removing those packages will also remove Cinnamon so some of these are more critical than they look at first glance

An alternative to upgrading VLC to the Debian version and removing some functionality (at least libgroupsock4 gets removed IIRC) would be to sandbox VLC using firejail. It comes with a profile for VLC. firejail runs the program in a security sandbox so it can access less of your personal files and hardens the system against malicious actions from any multimedia files specially crafted to exploit these VLC bugs. This could all be security theater though; are these bugs being exploited in the real world?

[KBD47]

I wonder if it would be best to only enable deb-multimedia when you need certain codecs and keep it disabled otherwise? Could Mint keep those few codecs in its own repo and do away with deb-multimedia?

[Zill]

SolydXK removed DMO some time ago and, having replaced my SolydXK DMO packages with the Debian versions, I haven't noticed any problems. Having said that, I am not a great user of multimedia and VLC tends to deal with most of my day-to-day AV requirements. However, note that there are some anomalies as not all DMO packages have Debian versions. For example, ffmpeg is not currently available in Debian stable, although I understand it should eventually return when Stretch becomes the new stable.

FWIW, I would be quite happy to see DMO go from LMDE. This should be relatively easy with new ISOs but the main problem will be removing it from existing installations. With SolydXK, "grizzler" produced a script to do this and this worked very well but it is still necessary for the user to check exactly what is going on.

• https://forums.solydxk.com/viewtopic.php?t=4030
• https://forums.solydxk.com/viewtopic.ph ... 014#p51014

[Fred Barclay]

My current version of VLC is 2.2.1 Should I try to update it somehow? I'm using Cinnamon.Will this be an issue addressed by some future update?

I don't know. You use the Ubuntu-based Mint, right? That setup might be different from LMDE (which is what I'm using). My first instinct would be to say, yes, find a way to update.
Now I wouldn't panic though... as long as you're not downloading random videos from online you should be (temporarily?) fine. All of the exploits I read--and I didn't read all of them--required the victim to play a specially-crafted file* that you are highly unlikely to have in your personal library.
But still, I would instinctively say to find a way to update it as soon as it is convenient.

Cosmos' concerns re the LTS nature of Ubuntu and the Ubuntu-based Mint spring to mind, with VLC not being properly maintained.

xenopeek: that's a very good point about firejail. Thankfully I've been running vlc in firejail and I haven't played any untrusted videos.

Code: Select all

# VLC media player profile
noblacklist ${HOME}/.config/vlc

include /etc/firejail/disable-common.inc
include /etc/firejail/disable-programs.inc
include /etc/firejail/disable-devel.inc
include /etc/firejail/disable-passwdmgr.inc

caps.drop all
netfilter
nonewprivs
noroot
protocol unix,inet,inet6
seccomp


# to test
shell none
private-bin vlc,cvlc,nvlc,rvlc,qvlc,svlc

As you can see there is thankfully a private-bin filter so an attacker will be limited in what he can launch outside of vlc. On the other hand, I don't know if any of the attacks required launching additional programmes... I don't believe they did so this wouldn't stop them, only (hopefully) mitigate the damage.
Network access is still allowed (due to vlc being used for streaming, I suppose) and the profile isn't terribly tight either. If you run firejail --audit /etc/firejail/vlc.profile you can see there are a few "MAYBE"s in there. Most concerning would be that /dev is entirely visible (probably because a few chaps use vlc to capture video) to firejailed vlc.
(Off-topic: fjaudit is shaping up nicely!)

I removed vlc several hours ago and reinstalled from Stable--it was harder than I expected. apt insisted on reinstalling from dmo even when I specified apt-get install -t stable vlc vlc-all-the-other-packages so I finally had to open the sources list, comment out dmo, and then install.

I use MATE, not Cinnamon, and if I want to stream something I'll just use my browser, so I may try removing the other dmo packages and seeing what happens. Flame-thrower time!

*"Specially crafted file"... ugh, I've been reading too many Microsoft bug reports.

EDIT: Thanks for the info, Zill.

[Fred Barclay]

For example, ffmpeg is not currently available in Debian stable, although I understand it should eventually return when Stretch becomes the new stable.

Good news--it's in jessie-backports.

Code: Select all

ffmpeg:
  Installed: (none)
  Candidate: 7:3.0.2-4~bpo8+1
  Version table:
     7:3.0.2-4~bpo8+1 0
        400 http://httpredir.debian.org/debian/ jessie-backports/main amd64 Packages

[Fred Barclay]

Whew... just finished removing all the DMO packages, not just VLC. So far I haven't had any problems playing files. Looking around on the internet it seems like Debian has done a much better job adding codecs than they used to, and I really like my security updates, so I'm trying to get as far away from deb-multimedia as possible.
I was really glad to hear that SolydXK quit using deb-multimedia; it gave me the last bit of encouragement I needed to remove all the deb-multimedia packages from my computer. I've done a bit of snooping around on the SolydXK forums and I've gained a lot of respect for the project; if they don't need deb-multimedia, then I don't either!

I wrote a reply detailing what I did, which xenopeek was kind enough to split into a separate tutorial at viewtopic.php?f=241&t=227270. If you're interested, then please try it out and let me know how well it worked!