Current state of security in VLC on Windows

A recent report from Secunia states that popular Windows applications don’t use the DEP and ASLR protections. It is true for VLC up to 1.0: the latest version at the moment, 1.1, supports permanent DEP mode, and ASLR on all of its DLLs.

One thing the report could have shown is the difference between applicatins built with MSVC or GCC. Adding DEP and ASLR in Visual Studio means adding /NXCompat and DynamicBase to the compilation options. With MinGW, there is a different trick. This article on my old blog is slightly outdated: ld in binutils 2.20 supports the –nxcompat and –dynamicbase options. So, now, the developers using GCC have no more excuse!

Let’s sum up the state of the security of VLC:

  • 1.0.5 is NOT SAFE on Windows. 1.0.6 brings a lot of security fixes, but this version was not released on Windows. And security features are not used.
  • 1.1.0 supports permanent DEP and ASLR (with DllCharacteristics flag, only on Vista/7) and termination on heap corruption
  • 1.1.1 supports the same as 1.1.0, and adds DEP on XP SP3 with SetProcessDEPPolicy
  • SafeSEH and stack cookies are not yet used

The developers using LibVLC should check their software: DEP won’t be activated if their executable doesn’t support it.

About these ads

9 thoughts on “Current state of security in VLC on Windows

  1. Many Popular Windows Apps Ignore Security Options | JetLib News

  2. I’m all for using the latest software almost straight away, but how much “not safe” is it not having the DEP and ASLR provisions? Are we liable to hack ourselves by playing a malicious video in VLC? Perhaps whilst simultaneously visiting a nasty web site in the web browser?

    If you like, you could either explain the issue, or point to someone else who does so.

    My current issues with VLC (I think I did update to 1.1?) are that a particular British “Freeview” video-recorder-to-USB TV-top-box produces video files that play without a time counter, and non-video “radio” files that don’t play at all. They play in WinDVD but then tend to make it crash. I have another TV box that records the same video sources with the time counter working in VLC, but won’t record the radio programmes at all. But this probably isn’t the place to get into that.

    • DEP and ASLR are exploit mitigations. They don’t prevent vulnerabilities, but their exploitation. If someone finds a buffer overflow in VLC, XP users will be at risk by playing a malicious file, or maybe visiting a website loading the vlc plugin and a malicious file. But Vista and 7 users may be protected, because making the exploit work on platforms with DEP and ASLR enabled is much harder.

  3. VLC crashes so often when watching TV coming from ADSL that VLC codecs are probably full of security bugs that could be exploited by rogue video distributors.

    I’m receiving Free.fr HDTV streams on a bandwidth limited link, so many packets are dropped and it seems VLC handles this badly. I’ve seen that a automatic crash report has been added to recent VLC version. I hope it will help you to fix those bugs.

    • If you have examples of streams that crash VLC, please share them on trac.videolan.org, to help us fix that.

      About your HDTV problem: don’t expect VLC to fix you bad connection. If you want to watch HD streams, you need a lot of bandwidth, period.

      • I do not expect VLC to fix my connection. I only expect that VLC do not crash every 5 minutes.

        Of course I could manually submit a crash report report after every crash (if even I knew what to do: is there something like a coredump on Windows?). But a new crash would occur before I submitted the first one. And when I’m watching TV, I do not want to submit bug reports.

        The auto crash report is the best thing I can do to help. And I hope that my limited bandwidth will help you to fix bugs.

      • If you want your bug to be fixed quickly, go to trac.videolan.org and post the URL of that TV stream.

        And I don’t understand why you could not post a bug report on Trac, when you go and rant here on an unrelated blog post.

        This is not a bug tracker, this is a blog.

  4. As I wrote above, the problem is not in the source video stream itself. The VLC problems seems to be in handling invalid/partial video streams that appear when a video stream has missing packets (due in my case to my too short bandwidth). Such a invalid video stream could probably be crafted by a bad guy.

    Your blog post is about security. Any VLC crash due to video stream input may be a potential security issue (but mitigated by the added features you reported).

    • Still, this is not a bug tracker. And I won’t be able to reproduce your bug, because I have a good enough connection. You should try to dump that stream, and send the resulting file to the Trac. And again, if you want your bug fixed, this is not the right place.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s