 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. |
|
|
|
 w8sdz join:2001-05-21 Port Orange, FL | 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. |
|