Read more about that issue in the release notes and the security advisory.

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.

Other important news: libVLC has a lot of new useful functions, like libvlc_set_user_agent(), or libvlc_video_set_callbacks() and libvlc_video_set_format() to replace the –vmem-* hack.

Enjoy this new release!

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.

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…)
• …