OZOPremium
join:2003-01-17
kudos:2 | reply to NICK ADSL UK
Re: 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:
If an attacker can cause an affected application to call LoadLibrary() while the application's current directory is set to one controlled by the attacker, that application may run the attacker's code from a specially named DLL also supplied in that directory. Attacker can not cause an affected application to call LoadLibrary(). If application is designed to call it - it will do without any attacker's help. What a BS they convey here... 
Again, the vendor is at fault here, and it should fix it ASAP by providing security update to everyone (without a suggestion to apply a registry hack manually just to make it to work). While the application developers may somehow help here (to make applications to be more secure) - it is not necessary in this particular case. Appealing to them to fix their applications is just misleading from the real cause of the problem here.
--
Keep it simple, it'll become complex by itself... |
|
 rcdaileyDragoonflyPremium
join:2005-03-29
Rialto, CA
2 edits | 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. |
|
OZOPremium
join:2003-01-17
kudos:2 | 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... |
|
1 edit | reply to OZO
said by OZO: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. If the OS since the beginning of time has contained the CWD, then wouldn't developers need to program around that by now?
Anyway, I have this little issue with Winamp. I have the patch loaded. I have the DWord value set to FFFFFFFF. I took an application, removed a DLL and placed it in a test directory, and started the application from the test directory, message that application has failed to start, reinstall may fix, change DWord to 0, application starts, back to FFFFFFFF, application doesn't start.
This article contains the instructions for checking for an insecure load. So, I go hm'mm, lets check out Winamp 5.581.
So, I have all the filters for process explorer as specified in the article, and also set:
Process Name contains Winam > include.
I navigate to a directory with an mp3 file and issue
start 07-BOB~1.MP3 (using the old dos 8.3 name) and I see that Winamp is looking for rsaenh.dll. It looked first in the winamp application directory, and then in the cwd, before looking in system32. So, I read over here that SERVMESS.dll is a good one to use in making dummy dll's, since it doesn't contain any functions. Having one lying around, I renamed it rshenh.dll and put it in the CWD, and got several hits on it in process explorer. Winamp never went to system32 where the real one was. Winamp didn't malfunction either. Now remember, that new DWORD is set at FFFFFFFF.
As far as I can tell, I have SafeSearch on. Says in this article calling SetDllDirectory will disable safe search. It certainly is following the non-safe search method, and is including the CWD. I put in the SafeDllSearchMode DWORD, set to 1, and still see CWD searched for that DLL first.
Point I'm trying to make is, there may more than just an OS issue here. I think I'll check a couple of other apps and see what happens. The process explorer approach looks like a good way to issue a verdict on individual programs, or my configuration of the OS. |
|
|
|
rcdaileyDragoonflyPremium
join:2005-03-29
Rialto, CA
1 edit | 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. |
|
 w8sdz
join:2001-05-21
Port Orange, FL | 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. 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
--
73 de w8sdz - sip:271752@us.voxalot.com
|
|
rcdaileyDragoonflyPremium
join:2005-03-29
Rialto, CA | 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 said by Frodo:Anyway, I have this little issue with Winamp. As far as I know, it's entirely possible to use the old unsafe DLL search order, it's just that the default is the one where system folders are searched first before the current directory. I think you should report your discovery to Winamp just in case it hasn't been done already. I seem to remember them having pretty active forums that the dev team follows.
--
Limited User Accounts.
Software Restriction Policies. |
|
w8sdz
join:2001-05-21
Port Orange, FL | reply to rcdailey
Re: Insecure Loading of Dynamic Link Libraries in Google Chrome said by rcdailey:You seem to have discovered what I found, but I wonder about that "-1" that OZO mentioned. I should have been more explicit. I used 0xFFFFFFFF, not -1.
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.
I agree. It means that Chrome did not adhere to Microsoft's documentation on how to safely load DLLs.
--
73 de w8sdz - sip:271752@us.voxalot.com
|
|
OZOPremium
join:2003-01-17
kudos:2
1 edit | 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 w8sdz - the use of explicit path when loading DLL is the way to avoid OS search for DLL in chain of locations defined in this article - KB2264107. But there is nothing wrong with using just simple name of DLL and allowing OS to search it in other 5 locations in this chain (excluding CWD, of cause, which creates this security risk). The only thing that the patch does presumably (of cause, we could be mislead by m$ here or they accidentally put s bug into it) - it removes CWD from the list of locations to search for DLL. Nothing more and nothing less.
If you set up the patch (by installing it and by hacking the registry manually), as you did, and Goolge is looking for a DLL - first of all, it's weird (were they relying on CWD to load?) and second, put that DLL into any place mentioned in the KB above. System, responsible for finding and loading DLL, should do it without returning an error to the application.
--
Keep it simple, it'll become complex by itself... |
|
w8sdz
join:2001-05-21
Port Orange, FL | said by OZO:the use of explicit path when loading DLL is the way to avoid OS search for DLL in chain of locations ... But there is nothing wrong with using just simple name of DLL and allowing OS to search it in other 5 locations in this chain (excluding CWD, of cause, which creates this security risk). Please read the MSDN document Dynamic-Link Library Search Order (updated 8/19/2010) »msdn.microsoft.com/en-us/library···85).aspx regarding the registry key SafeDllSearchMode, in particular this statement:
Windows XP and Windows 2000 with SP4: Safe DLL search mode is disabled by default. To enable this feature, create the SafeDllSearchMode registry value and set it to 1. Safe DLL search mode is enabled by default starting with Windows XP with SP2.
I checked the registry on my PC's XP SP3 and discovered it had been set to zero. This means that CWD was second in the search order. I have no idea what program made that change. I immediately changed it to 1.
Some programs use DLLs that have the same name as those in the system directory or other directories in the DLL search path. If CWDIllegalInDllSearch is set to anything other than 0xffffffff and the programmer uses CWD to load the DLL it could load a different DLL version or a DLL with a different purpose.
--
73 de w8sdz - sip:271752@us.voxalot.com
|
|
rcdaileyDragoonflyPremium
join:2005-03-29
Rialto, CA
1 edit | 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. |
|
rcdaileyDragoonflyPremium
join:2005-03-29
Rialto, CA | 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. |
|
w8sdz
join:2001-05-21
Port Orange, FL | Regarding the SafeDllSearchMode key
said by rcdailey: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. Using the normal Microsoft convention if this was the case then the registry key would be named SafeDllSearchModeDisable or DisableSafeDllSearchMode. Then if the key value was a 1 it would disable Safe DLL Search Mode.
--
73 de w8sdz - sip:271752@us.voxalot.com
|
|
rcdaileyDragoonflyPremium
join:2005-03-29
Rialto, CA
1 edit | 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. |
|
