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 \\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/> ~
~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
