Microsoft admits new attack route for massive DLL flaw

Nice reporting - you've managed to avoid telling anyone which versions of Windows this affects... I bet you had to try really hard to achieve that!

By SwissMac on 24 Aug 2010

@SwissMac

This issue goes back to Windows 1.0. Affected versions will be every version of Windows every made - it is how Windows works, if no path is specified, when a library is called, it checks the current directory first, then it looks in the path for it, then the System directory.

A lot of applications over the years (much more than 40) have been written this way, I would guess a lot of bespoke software, which probably isn't maintained any more, would probably also fall foul of this flaw.

On the bright side, Linux and OS X have similar flaws - if the library path isn't directly specified, when loading a library, they will search the defined paths. It is therefore easy to put a "bad" library in the library search path, or to add the directory where the malformed library is, to the front of the path...

Both methods allow the programmer greater freedom - for example a lot of code works with specific versions of libraries, so, by not specifying the path, it forced Windows to use the version of the library, where the executable was, as opposed to the latest version in the System directory - this was often a problem with OCX controls in the early days, on Windows and I've worked on several projects, where a purchased custom control only worked with a hacked version of a DLL and that DLL had to be in the executable directory, which is why I say a lot of bespoke software will be affected.

System administrators in larger corporations will have to do a lot of regression testing, to ensure that all their software still works - and if the developer or source code is no longer available, the affected machine won't be upgradable.

Why don't the developers hard code the path to their "customised" DLL, you ask? Because the user can select the destination of the application at install time, which means that at compile time, the path is unknown...

By big_D on 24 Aug 2010

Missing something somewhere

I'm not saying there isn't an issue, but as Big_D points out in his final paragraph, developers CAN'T hard code the full path. So the bit that reads "When applications load dynamic link libraries where the programmer has been sloppy and not used the full path name" is absurd if taken literally. No programmer can know the full path name when writing things (I did once put WINDOWS on C: and PROGRAM FILES on D:)

So somewhere there is a flaw, but it's badly explained.

And since I've not got a shared network drive on my PC at home, and I can't see that many people without pony-tails have, I'm finding it difficult to see this as a massive flaw.

By AdrianB on 24 Aug 2010

It is a shame the developer can't put the path into a variable that is set on install when the user selects the install location.

By SwissMac on 24 Aug 2010

"It is a shame the developer can't put the path into a variable"

They can - and it may be that this is one of the "proper" ways of doing it. Though, it's not what the text above refers to because using the full path is not the same as using a variable containing the full path.

However, even if it's done like that, it seems to me to leave issues. E.g., if someone updates a library of common routines on their PC, then what happens to the variable that was set up on installation, that now points to an old version?

So I'm still unsure what the real issue and the recommended action is.

By AdrianB on 24 Aug 2010

Variable path

The problem is, the path to the library is a pre-compiler instruction, not something the code itself does.

The instruction tells the compiler to put the address of the library into the code. All compilers have always done this, which is why Linux, UNIX and OS X have a similar problem, as outlined above.

The problem here, is that Windows starts searching in the directory where the executable was launched, when the library isn't there, it then searches the through the directories in the PATH environment variable. If Linux/UNIX/OS X has "./" in the library path variable, it will do exactly the same thing, although ./ should not be in the path!

Most programs will either put themselves in &programfiles&\MyApp\Libs or in %systemroot%\System32. A problem arises here, if two companies use the same name for their library, in which case, the one with the highest version number will replace the one with the lower version number and the other program won't work.

A second problem is when an application needs a specific version. An example is the commctl.dll library, several custom controls used to use a specific version, but the library was regularly updated to add new features in the early days. To get around this, the custom control creators used to include the version of commctl.dll they needed, which needed to be in the directory where the application was stored. This was the only way to get around the problem. If the library was in the path, every program which needed the latest version would fail, because it would find the old version first! If the old version wasn't in the application directory, the application would fail to run, because the version of the library wasn't compatible and would cause fatal errors.

It also allows an app to keep working, if Microsoft fix a bug in a DLL, which stops the app working. The old version can be slapped in the app directory, until the app can be repaired - if the source code or the developer is still around... This protects the rest of the system, but leaves the app still working, if susceptible to any security flaw, that the patch fixed.

It makes Windows very flexible, but it also causes problems if the system is exposed to malware.

There are two caveats here:
1. The user must be logged in as an administrator (bad practice anyway), or the malware must use an exploit in order to raise its rights, so that it can slip the library into the directory with the executable.

2. It has to target a specific application and hack the shortcut, so that it manages to run the app, but gives a new target directory, with the library in it. This will only work for shortcuts the user generated or if the user is logged on as an administrator.

3. UAC in Vista and Windows 7 will catch the malware out, here, because it will ask the user to confirm that they want to copy the library to a protected directory or change a system shortcut (user generated shortcuts wouldn't be affected).

The exception to this rule, is if the user goes to an "untrusted" directory and double clicks on a file there to launch an application.

This is the key to the fault. You need to find an app which calls a known DLL without a path, then you need to provide a hacked version of that library in the same directory as the data file the user is expected to click on.

This is a highly targeted attack - although with big names, like Apple and Adobe being vulnerable, there are probably a lot of users to attack out there. But you still need to trick them into opening a directory on a WebDAV connection or an infected USB stick, for example, with a music (or video) file and the hacked library.

That is a lot of work, and I would think, at the moment, it is more likely to be used in a spearphishing attack, as opposed to a general malware attack.

Opening the application and then browsing to the location and opening the file WILL NOT use the exploited library.

If the app is already running and the user clicks on a file in an infected directory, the exploited library WILL NOT be called.

Microsoft also has a page for developers on how to securely call DLLs:
http://msdn.microsoft.com/en-us/library/ff919712%2
8VS.85%29.aspx

By big_D on 25 Aug 2010

Thanks Big_D - interested when you say "If the app is already running and the user clicks on a file in an infected directory, the exploited library WILL NOT be called". I'm sufficiently old-fashioned that if I want to read a Word document (say), I'll very often fire up Word first, without a file, rather than double-click the document. Sounds like a good habit to cultivate when trying to access anything off my hard-drive.

By AdrianB on 25 Aug 2010