Nixpkgs: VLC media player 2.2.8 Vulnerable to Arbitrary Code Execution (CVE-2018-11529)

[stefano-m]

Issue description

VLC 2.2.8 is vulnerable to arbitrary code, a PoC has been made public. The issue is fixed in VLC 3.0.3

Not that although the PoC has been tested on Windows, I could crash the currently installed version of VLC in NixOS. This makes me believe that it's just a matter of crafting an appropriate mkv file.

See http://seclists.org/fulldisclosure/2018/Jul/28

From the mailing list message:

VLC media player through 2.2.8 is prone to a Use-After-Free (UAF) vulnerability. This issue allows
an attacker to execute arbitrary code in the context of the logged-in user via crafted MKV files. Failed
exploit attempts will likely result in denial of service conditions.
Exploit can work on both 32 bits and 64 bits of VLC media player.

This vulnerability is not yet listed on VLC's website (https://www.videolan.org/security) but note that there are still other vulnerabilities that may grant an update to the latest (3.0.3) version.

Steps to reproduce

1. generate the poc.mkv file with python2 using the script from the mailing list (using a VM is strongly advised)
2. try to play the file with VLC 2.2.8
3. VLC crashes

This has been fixed in VLC 3.0.3

Technical details

• system: "x86_64-linux"
• host os: Linux 4.14.51, NixOS, 18.03.132768.94d80eb7247 (Impala)
• multi-user?: yes
• sandbox: no
• version: nix-env (Nix) 2.0.4
• channels(root): "nixos-18.03.132768.94d80eb7247"
• channels(user): "nixpkgs-18.03.132821.56fad146a12"
• nixpkgs: /nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs

$ vlc --version
VLC media player 2.2.8 Weatherwax (revision 2.2.7-14-g3cc1d8cba9)
VLC version 2.2.8 Weatherwax (2.2.7-14-g3cc1d8cba9)
Compiled by nixbld on  (Nov 21 2017 19:45:48)
Compiler: gcc version 7.3.0 (GCC)
This program comes with NO WARRANTY, to the extent permitted by law.
You may redistribute it under the terms of the GNU General Public License;
see the file named COPYING for details.
Written by the VideoLAN team; see the AUTHORS file.

[vcunat]

This seems an issue only on the 18.03 branch. Upgrading vlc to 3.0.3 would probably be easiest, but I wonder if that would be a too intrusive change (given the large numbering shift).

[stefano-m]

Thanks for the feedback.

FYI I tried a trivial overlay (i.e. update version number and sha256 signature) for vlc and sadly it did not build (don't have the logs now, but it complained it could not find gcc-c99). I think the VLC team changed (at least slightly) the way they build the software.

I am not aware of any patches for version 2.x so I'm afraid the only fix would be to update to 3.0.3.

Let me know if I can help further.

[peterhoeg]

There was quite a bit of work that went into packaging vlc3 but that should basically be just 2 commits that need backporting. The main thing is qt4 -> qt5. I'd argue that something as exposed as a media player should always be updated to the latest. It's really in the same category as browsers IMHO.

[coretemp]

I think any media player when started with a single file or folder as an argument should run via a separate account with no access to any files in the users homedir.

So, vlc myfile.avi when opening a new folder shows no files at all, but plays the myfile.avi media.

OTOH, vlc will have access to everything as is the case now. This change alone reduces the attack surface by an enormous amount.

Updating to the latest version is just a way to mitigate some risk, which is better than distributing known to be insecure versions. In reality, I think everyone can agree that VLC/MPlayer all are flawed by design regarding security. Doing something like I suggested is the least of what I would expect a proper IT department to implement in a corporate environment.

[peterhoeg]

Have a look at firejail to limit the exposure.

[peterhoeg]

@stefano-m, will you prep a PR with the backported commits?

[stefano-m]

@peterhoeg I can try and to that according to my existing commitments.

Would you mind giving some pointers about the PR process please?

[vcunat]

@stefano-m: there's nothing much special – some description is in https://github.com/NixOS/nixpkgs/blob/master/.github/PULL_REQUEST_TEMPLATE.md and the linked CONTRIBUTING.md. Cherry-picks are best done with git cherry-pick -xe, as described deeper in docs.

[stefano-m]

A couple of questions:

• vlc on master builds with Qt5 by default, while the 18.03 branch does not. Backporting master, I have kept the Qt5 default which builds just fine. Let me know if you have any objections to this
• I also backported libsForQt5.phonon-backend-vlc (0.9.0 -> 0.10.1) in the same commit as the older version would not build. I hope this is not a problem, however I am not sure how I can put this in the commit message (unless something like vlc 2.2.2 -> 3.0.3; libsForQt5.phonon-backend-vlc 0.9.0 -> 0.10.1) is an acceptable solution. (I could also have 2 commits, but I think they'd have to be built together anyway).

Thanks

[peterhoeg]

  not. Backporting master, I have kept the Qt5 default which builds just

Sounds good to me.

  solution. (I could also have 2 commits, but I think they'd have to be
  built together anyway).

Please have 2 separate commits even if they both need to be applied.

[stefano-m]

@peterhoeg and @vcunat I've just posted the PR.

[stefano-m]

PR merged. Closing issue.