VLC For Win8: building the new compatibility layer

As you can see, we are doing a KickStarter for the Windows 8 (WinRT) port of VLC media player. The goal is to take our existing code, which already works on Windows 8’s “desktop mode”, and make it run on WinRT, the “Metro” interface.

Porting code to WinRT offers significant challenges, mainly caused by the changes in the APIs. A lot of functions we were using, like LoadLibrary, are not available anymore, and replaced by slightly different functions (like LoadPackagedLibrary). Those might not be too hard to integrate into our current code base.

Other APIs, like sockets, were replaced by their COM interfaces counterpart (for instance Windows.Networking.Sockets). They are used to provide asynchronous interfaces for code running under WinRT. They got inspiration from mobile applications and the “always responsive” goal: a WinRT application should not use blocking code, and should go to sleep or wake up quickly if needed. With COM interfaces, the code polling the socket is executed in another process, and the data is provided through a callback. This changes a bit the usual networking code (connect->select->read->select>…) and we need to write a large layer of compatibility code.

After all of that, we still have to solve the issue of packaging. We already experimented a bit with side loading, which offers an easy way to distribute applications, but the real goal is to push VLC media player to the Windows Store.

So, why are we doing this? Windows 8 is happening, it is now preinstalled on most of the new computers.

Why am I excited to work on this port? This KickStarter will give us the opportunity to work full time on WinRT for a few months, and solve all these challenges for us, but also for other open source projects. We already know how to create a compatibility layer for different operating systems, so we will be able to build one for WinRT. We could also come up with guidelines on using free software toolchains to build WinRT applications.

Basically, we’re paving the way to WinRT for opensource libraries and applications, with the nice side effect on running VLC on Windows 8.

Help us make this project a reality! Please contribute to our Kickstarter for Windows 8!

Fixing the DLL loading vulnerability

Update 24/08/2010: Microsoft published an advisory, there’s an article from the MSRC about the preloading DLL vulnerability, and a tool that fixes the problem. And if you want to know more, there’s an MSDN article.

Update 25/08/2010: if you came here from golem.de, heise.de or h-online.com, good for you! The articles on these websites are blatantly wrong, and their proposed solution doesn’t work . You will find here the real solutions, and links to the relevant blog posts and advisories.

Look! A new shiny vulnerability, affecting a lot of Windows applications! OMG OMG OMG we’re DOOMED!

</crazy mode off>

OK, let’s get serious. This vulnerability is actually a very old one. It is there because the DLL search order includes the current directory (if someone can tell me why, I would be delighted to know that). Here is the search order (source: MSDN):

If SafeDllSearchMode is enabled, the search order is as follows:

  1. The directory from which the application loaded.
  2. The system directory. Use the GetSystemDirectory function to get the path of this directory.
  3. The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched.
  4. The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
  5. The current directory.
  6. The directories that are listed in the PATH environment variable. Note that this does not include the per-application path specified by the App Paths registry key. The App Paths key is not used when computing the DLL search path.

If SafeDllSearchMode is disabled, the search order is as follows:

  1. The directory from which the application loaded.
  2. The current directory.
  3. The system directory. Use the GetSystemDirectory function to get the path of this directory.
  4. The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched.
  5. The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.

For the record: disabling SafeDllSearchMode means that you’re stupid, or that you’re using a Windows before XP SP1 (note that this is not exclusive).

So, let’s assume that your application tries to load a DLL that isn’t present, either in your application directory, or in the system directories. Then, the application will try to load the DLL from the current directory. And that’s it. If there’s a DLL with the same name in that folder, it will be loaded in the application. That’s why you can get owned by opening a file in that same directory: it sets the current directory of the application to the file’s folder.

OMG OMG OMG we’re DOOMED, and it’s incredibly easy to exploit me!

So, now, let’s take a look at the fix. This is an OS flaw. You can’t fix all your applications yourself. H.D. Moore has some sysadmin fixes that you can apply to prevent the exploit from coming on your computer. But your applications will still be exploitable.

If you’re a developer, though, you can fix your application. There’s a function that can remove the current directory from the DLL search path: SetDllDirectory. From MSDN:

After calling SetDllDirectory, the DLL search path is:

  1. The directory from which the application loaded.
  2. The directory specified by the lpPathName parameter.
  3. The system directory. Use the GetSystemDirectory function to get the path of this directory. The name of this directory is System32.
  4. The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched. The name of this directory is System.
  5. The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
  6. The directories that are listed in the PATH environment variable.

So, if you pass a safe directory(let’s say, C:\Windows\System32, or your application directory) as argument to SetDllDirectory, you effectively remove the current directory from the search path! It works, I tested it for you 🙂

But that’s not the end: you have to wipe out the PATH to be safe. From the metasploit blog:

If the application is trying to load a DLL that is normally found within the PATH, but not the Windows system directories, and the PATH contains environment variables that have not been set, then the literal value of the environment variable will be treated as sub-directory of the working directory (the share). For example, if %unknownvariable%\bin is in the system PATH, the share will be searched for a directory called “%unknownvariable%\bin” and the target DLL will be loaded from within this sub-directory.

And if you test  your application with ProcMon, you will surely see that a lot of (potentially unsafe) directories are added to the PATH, and used to look for the DLL. So, remove all the useless directories from the PATH if you can!

(And now, for the disclaimer: this blog post is not endorsed by Microsoft, and if you want to be really safe and know the best solution to employ, wait for Microsoft’s patches and workarounds. But if you trust me enough (you fool… *evil laugh*), you can try that fix on your application, and maybe protect your users. )

Actually, that fix is encouraged by Microsoft, and David Leblanc wrote about it in February 2008.

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.

5 reasons to wait for VLC 1.1

The next VLC media player release is drawing near (it will be ready when it will be ready), and it comes with a lot of new features and bugfixing:

GPU decoding

One of the coolest new features (do I say that because I worked on it?). We can now decode videos using a graphic card, with DxVA on Windows Vista and 7, and VAAPI on Linux. If you want to test, we are looking for a little help.

Media library

That is a feature a lot of you are waiting for. We will now store a list of all your files in a database using Sqlite.

Windows 7 integration

Some of you already know that VLC media player 1.0.3 is compatible with Windows 7. We didn’t stop there. The next release will bring you cool taskbar buttons à la WMP, jump lists, thumbnails, etc.

Interface rework

I like the grey VLC. Maybe I have forgotten what the word “ergonomic” means. But some of the developers have not, and they’re doing an amazing work with the Qt interface, to change the layout, add nice effects and make it a lot prettier.

Lua extensions

People who read my previous blog know that I love tweaking VLC with Lua scripts. One developer had a nice project for this year’s Google Summer of Code: adding a way for lua scripts to change the interface. Now, lua scripts can add menus, open windows, etc. OK, it doesn’t sound cool at first, but what you will see thanks to this code is really nice: automatically downloading lyrics and subtitles, finding data on IMDb, doing a Google search, whatever you want! Isn’t that cool?

Still not convinced?

These were the features I’m excited to see in the next release. But that’s not all:

  • N900 port
  • Milkdrop visualizations using projectM
  • WPL and ZPL playlist support
  • desktop mode for Direct 3D video output (you know, the trick to show the video as a wallpaper…)