May I stand in for Marc? I'm sure he'll correct me if I'm wrong... :)
For SafeDLLSearchMode in XP SP2 and after, "enabled by default" means no registry value is enabled and you must create the registry value and set it to 0 to disable it. http://msdn.microsoft.com/en-us/library/ms682586(VS.85).aspx As regards SafeDLLSearchMode, it does not guarantee mitigation, because an application can try to load a .dll that isn't in any of the locations before reaching the CWD. I would imagine there are plenty of applications that might attempt to load a user-provided .dll containing custom code. Carl From: Ziots, Edward [mailto:[email protected]] Sent: Tuesday, August 24, 2010 5:28 PM To: NT System Admin Issues Cc: [email protected] Subject: RE: DLL hijacking vulnerabilities more question Marc, He is what I don't get, and I have been asking on a few lists. Including Microsoft's Private Security Discussion list, and I can't get a straight answer that GELS in my head, just trying to put two and two together here and get the concept down accordingly. Here is the exact sentence from the Advisory: 2264107 This update introduces a new registry key CWDIllegalInDllSearch that allows users to control the DLL search path algorithm. The DLL search path algorithm is used by the LoadLibrary API and the LoadLibraryEx API when DLLs are loaded without specifying a fully qualified path. Now from Security Advisory 2269637 Mitigating Factors: . This issue only affects applications that do not load external libraries securely. Microsoft has previously published guidelines for developers in the MSDN article, Dynamic-Link Library Security, that recommend alternate methods to load libraries that are safe against these attacks. It basically talks about using SafeDLLSearchMode setting, which is enabled in XP SP2, SP3, but when I look on my XP SP2, SP3 machines its not set for either the Session Manager ( Global Settings) or the File Image Execution Options. Therefore the article it references is not true in my eyes. I also can't get a straight answer if you do apply the SafeDLLSearchMode to the workstations, if that is going to be proper enough mitigation. Because the solution in 2264107 looks like it could break a ton of applications. I don't see a reason that SafeDLLSearchMode needs to be applied to servers since users aren't on servers running the vulnerable applications interactively, they are only accessing the shares via the network that have the application and its associated .DLL's etc etc. Scenario 2: The application is started from a remote folder, such as \\remote\shareremote\share) Collapse this tableExpand this table CWDIllegalInDllSearch Value Behavior of the DLL search path in LoadLibrary and in LoadLibraryEx 0xFFFFFFFF Removes the current working directory from the default DLL search order 0 Uses the default DLL search path that was mentioned earlier 1 Blocks a DLL Load from the current working directory if the current working directory is set to a WebDAV folder 2 Allows DLL Load from the current working directory if the current working directory is set to a remote folder. Note that DLLs that are loaded from a WebDAV share are blocked if the CWD is set to a WebDAV share. No key or other values Uses the default DLL search path that was mentioned earlier So if I was to deploy this to all my workstations as a mitigation method, and I had applications that do load from shares, then I would set this setting to ? (0) is the default, and if I understand it correctly it should follow the default DLL search path as follows: Why would I even set this to (1) I blocked WEBdav at the firewall, and wouldn't setting this value to (2) for the remote share scenario be the same as loading it from the directory the application is loaded, which is <file:///\\servername\sharename> \\servername\sharename? The LoadLibrary function and the LoadLibraryEx function are used to dynamically load DLLs. The following is the DLL search order for these two functions: 1. The directory from which the application loaded 2. The system directory 3. The 16-bit system directory 4. The Windows directory 5. The current working directory (CWD) 6. The directories that are listed in the PATH environment variable I would assume that it is correct that the Application Directory is the first location that the application should be looking for .DLL's that it needs to load, then the System Directory ( Assuming C:\) then so on and so forth till it gets to the path statement directories. If you have done your mitigation by blocking SMB and WEBDAV at the perimeter ( both ingress and egress) then the only vector of attack I can see is someone hitting an untrusted share when loading the application, and if you have control to the application servers these users are going to, then that isn't much of an attack vector. Is there something in the logic that I am going through that isn't making sense. I am trying to ascertain the real-risk from this thing, given the controls that are in place and could be put in place, before going to an all hands on deck scenario just to protect my organization when it might not be warranted. Edward E. Ziots CISSP, Network +, Security + Network Engineer Lifespan Organization Email:[email protected] Cell:401-639-3505 -----Original Message----- From: Marc Maiffret [mailto:[email protected]] Sent: Tuesday, August 24, 2010 4:44 PM To: NT System Admin Issues Subject: RE: DLL hijacking vulnerabilities It is being exploited all over the place that we are tracking. We are writing a blog post on the matter right now to be posted on http://blog.eeye.com soon given the massive number of exploit servers and exploit frameworks (criminal ones, not just metasploit) that have all been weaponized for this vulnerability. A lot of the exploits are over WebDAV and as such using the Microsoft hotfix and blocking webdav for applications started in C:\Program Files and I would suggest blocking the current working directory all together when it is an application started from \\remote\shareremote etc... This last sentence will make more sense if you read the spec in the MS KB article: http://support.microsoft.com/kb/2264107 -Marc -----Original Message----- From: Andrew S. Baker [mailto:[email protected]] Sent: Tuesday, August 24, 2010 9:17 AM To: NT System Admin Issues Subject: Re: DLL hijacking vulnerabilities Because it is being exploited more readily now... ASB (My XeeSM Profile) <http://XeeSM.com/AndrewBaker> Exploiting Technology for Business Advantage... Signature powered by WiseStamp <http://www.wisestamp.com/email-install> On Tue, Aug 24, 2010 at 11:58 AM, Ben Scott <[email protected]> wrote: On Tue, Aug 24, 2010 at 9:40 AM, Andrew S. Baker <[email protected]> wrote: > There is now an Microsoft-supplied workaround for the DLL vulnerability that > was publicized below: I don't understand all the hoopla about this vulnerability. People have been complaining that the search path behavior in Microsoft systems is insecure for literally decades. People had this criticism for *MS-DOS*. Why is it suddenly getting attention? -- Ben ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
