Broadband Tech > Security > Security > Insecure Loading of Dynamic Link Libraries in Windows Applic

Insecure Loading of Dynamic Link Libraries in Windows Applic

I don't know why they're doing this, but the article (Vulnerability Note) contains a lot of misleading information.

For example, the article implies that the problem was created by application developers, while it is clearly not. Application developers are not at fault here, the vendor (m$) is. Windows OS initially included CWD (current working directory) into the list of locations to search for DLLs. That's the main (and only) problem here and CWD should not be listed in search places for DLLs in the first place.

As result of this bias, the article offers misleading suggestions too. For example it suggests that developers should call SetDllDirectory() with a blank path before calling LoadLibrary(). Yes, it will mitigate the potential problem. But the same way will do the setting of a full path where to search for particular DLL or any other similar approaches. Such suggestions just distract from the solving of the actual problem (which is fixing the OS by removing CWD from the list). And, BTW, what if application loads DLL without calling LoadLibrary() function (as it happens in many cases when developers rely on OS to load it automatically)? How this recommendation of calling SetDllDirectory() first can be accomplished then? Why they didn't mention this more common case at all?

I guess that they simply don't know what they're talking about. Just read this statement:

Isn't this related to the WebDAV thread?

»Mircosoft WebDAV patch out!!!

I downloaded and applied the "patch" and installed the global registry entry and also disabled WebClient. I know, you mean MS is the vendor, but how long will they take to put out a real fix and the patch will work for the time being.
--
Human nature abhors an empty closet.

rcdailey - there is a very small difference between "real fix" and the "patch" already offered. The real fix should set registry value CWDIllegalInDllSearch to "-1" automatically instead of requiring to do the hack manually (as it is required now in the patch). That's it.

Or they could remove CWD from list of search locations permanently without the need of any new registry values at all... Which is even better.
--
Keep it simple, it'll become complex by itself...

reply to OZO

reply to NICK ADSL UK
Gotta turn in, but I tested Outlook Express, an old VLC and Winamp. I retested Winamp the same way I tested VLC. Didn't see a current directory hit out of VLC and did out of Winamp. I think the VLC is 0.86i.

I issued from a command window in the CWD:
..\progra~1\winamp\winamp.exe 07-BOB~1.MP3
and
..\progra~1\videolan\vlc\vlc.exe 07-BOB~1.MP3
for the two media players.

reply to Frodo
I did find something else that the patch will break. I know it is the patch that broke it at this time. Google Chrome installs a file named "avutil-50.dll" when you install the program and when it updates, a new copy is added. When I patched two systems with Chrome installed, using the global patch with FFFFFFF as the dword value, Chrome complained about not being able to find "avutil-50.dll" and suggested re-installing the program. This did not help. Finally I found a tip on a similar issue with the file and simply made a copy of "avutil-50.dll" and placed it in the Windows folder. That's a crude fix, but it works to eliminate the error message in Chrome. Chrome will probably work even with the error message popping up, but it's an annoyance. I wonder whether Google will become aware of this issue at some point and fix their app? I suppose I could report this, but it seems I'd have to create a Google account to do this and I'm not sure I care that much.

--
Human nature abhors an empty closet.

reply to OZO

Re: Insecure Loading of Dynamic Link Libraries in Google Chrome

said by OZO:

rcdailey - The real fix should set registry value CWDIllegalInDllSearch to "-1" automatically instead of requiring to do the hack manually (as it is required now in the patch). That's it.

You seem to have discovered what I found, but I wonder about that "-1" that OZO mentioned. Looking at the file explaining the patch, it seems to me that a "-1" value for the dword would cause Windows to use the default search path, because a "-1" would be "no key or other values" as explained in the document. Anyway, 0xFFFFFFFF does appear to remove the CWD from the search path, but that must mean that Chrome uses the CWD as a place to put a copy of avutil-50.dll.
--
Human nature abhors an empty closet.

reply to Frodo

Re: Insecure Loading of Dynamic Link Libraries in Windows Applic

reply to rcdailey

Re: Insecure Loading of Dynamic Link Libraries in Google Chrome

reply to w8sdz

said by w8sdz:

said by OZO:

rcdailey - The real fix should set registry value CWDIllegalInDllSearch to "-1" automatically instead of requiring to do the hack manually (as it is required now in the patch). That's it.

I did that and immediately discovered that Google Chrome refused to load because it couldn't find one of its own DLLs. Apparently the programmer forgot to use an explicit path when loading the DLL.

Programmers should read this Revised 8/19/2010 MSDN article "Dynamic-Link Library Security"
»msdn.microsoft.com/en-us/library···85).aspx

»msdn.microsoft.com/en-us/library···85).aspx

reply to w8sdz
The other thing this taught me that if I want the patch to work, I have to put into each user account separately. I'm thinking about putting it into the Administrator account, too.

Well, I checked the Administrator account in Safe mode and the Dword value was already there, probably because I had entered it in the other administrator account that I use. Ain't the registry wonderful
--
Human nature abhors an empty closet.

reply to w8sdz
That article you quoted is confusing to some extent. It says exactly what you say, but look at the last sentence: Safe DLL search mode is enabled by default starting with Windows XP SP2.

That means that if you have Windows XP SP2 or SP3, you don't need a registry entry to enable this function. If you have a registry entry, it is probably there to _disable_ the function. It was set to "0" so it was disabled. Setting it to "1" should have enabled it again. Deleting the key should also restore the default if you have Windows XP SP2 or SP3. However, if you don't know how the key got into the registry, then removing it might have some other consequence.

I checked my registry in Windows XP SP3 and I don't have the SafeDLLSearchMode registry value. By default, it should be enabled based on the article.

I can see why a programmer would have issues with how this is enabled or not enabled with Windows XP in different versions.
--
Human nature abhors an empty closet.

Regarding the SafeDllSearchMode key

Yes, that would be logical, but the fact that they require that you _create_ the key seems to throw logic aside. They assert that the function is enabled by default in Windows XP SP2 and later, so if it is enabled by default and there is no registry entry regarding it, why would any user or application insert a registry entry unless to override the default? Overriding the default would allow for control of the mode, but MS isn't using the logic that you describe when it comes to naming the entry.

Then again, can we expect MS to always to follow their own normal convention?

p.s. Maybe it was too early when I posted this. It may well be logical to suggest adding a registry entry if the purpose of that entry is to override the default safe search mode in order to change the order of the search or even to disable it. One registry entry would be good enough for that, I guess.

--
Human nature abhors an empty closet.

reply to NICK ADSL UK

Re: Insecure Loading of Dynamic Link Libraries in Windows Applic

»support.microsoft.com/kb/2264107

Thank you w8sdz for the update.
It's nice to see that m$ makes yet another tiny step forward to real solution - which is removing CWD from the list automatically, once and for all
--
Keep it simple, it'll become complex by itself...