WIN DLL FILE VULNERABILITIES

http://msdn.microsoft.com/en-us/library/ms682583(v=vs.85).aspx
http://blogs.technet.com/
http://www.nruns.com/_downloads/23C3-Berlin-Bluetooth-Hacking-Revisited-Thierry-Zoller.pdf

http://blog.zoller.lu/2011/08/tools-whitepapers-talks.html?m=1

https://www.metasploit.com/redmine/projects/framework/repository/raw/external/source/DLLHijackAuditKit.zip

http://msdn.microsoft.com/en-us/library/hh310514(v=vs.85).aspx


★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★

CVE-2010-x+n - Loadlibrary/Getprocaddress roars its evil head in 2010

Subscribe to the RSS feed in case you are interested in
updatesAfter Acrossecurity, published an interesting vulnerability
and HDmoore appears to have stumbled on the same issue, I decided to
investigate on my own. I am not 100% sure it's the same bug but I am pretty
confident.

While it is known since years and Microsoft even dedicates a KB article to
it, vendors appear to still have issues with using
Loadlibrary/Getprocadress correctly.Above does not show vulnerable examples
(i.e the dll is not effectively loaded)This issue appears to have been
first discovered by Georgi Guninski (who else) in 2000, so it is not a new
weakness and defensive mechanisms have been introduced into development
languages as well as windows itself to mitigate this risk (if properly
used)If

I will find more time this week I'll publish more details and backround as
to introduce counter measures and checks into your hopefully mature
Development Lifecycle.In summary :If loadlibrary is not called correctly
AND/OR DLL Search path is not hardened opening a file located on a share
will lead to DLL files being located on the share and code being executed
that is within that DLL.

Above is an example of Photoshop.Until then know that this issue can be
mitigated by deploying proper GPO policies that disables searching for DLLs
on UNC paths (Documented in
http://support.microsoft.com/kb/2264107)Development Best practises that can
protect against this weakness/vulnerability :Do not use the SearchPath
function to retrieve a path to a DLL for a subsequent LoadLibrary call.

Why : http://msdn.microsoft.com/en-us/library/ms684175(VS.85).aspxMore to
follow in the following daysTools to detect said bug class :DLL Hijacking
Audit Tool v2 by Rapid7/HDmoore and Blog post (Recommended read)Rapid7 Blog
post (Interesting backround
information)Procmon (Sysinsternals)Filemon (Sysinsternals)Mitigate this
particular attack vector through GPO policies:
http://support.microsoft.com/kb/2264107More information from the SRD
Team (recommended read)More information :

Paper by Taeho Kwon and Taeho Kwon entitled Automatic Detection of
Vulnerable Dynamic Component LoadingsDLL preloading Microsoft Security
Response Center blog Official security AdvisoryExpect a lot of applications
vulnerable to this bug and my title CVE-2010-x+n probably makes sense by
now. Another low hanging fruit to watch out for.Thierry Zoller


●●●●●●●●●●●●●●●●●●●●●●●●●



LoadLibrary function

53 out of 116 rated this helpful - Rate this topicLoads the specified
module into the address space of the calling process. The specified module
may cause other modules to be loaded.For additional load options, use
the LoadLibraryEx function.

Syntax

C++ HMODULE WINAPI LoadLibrary( _In_ LPCTSTR lpFileName );

Parameters

lpFileName [in]The name of the module. This can be either a library module
(a .dll file) or an executable module (an .exe file). The name specified is
the file name of the module and is not related to the name stored in the
library module itself, as specified by the LIBRARY keyword in the
module-definition (.def) file.

If the string specifies a full path, the function searches only that path
for the module.If the string specifies a relative path or a module name
without a path, the function uses a standard search strategy to find the
module; for more information, see the Remarks.If the function cannot find
the module, the function fails.

When specifying a path, be sure to use backslashes (\), not forward slashes
(/). For more information about paths, see Naming a File or Directory.If
the string specifies a module name without a path and the file name
extension is omitted, the function appends the default library extension
.dll to the module name. To prevent the function from appending .dll to the
module name, include a trailing point character (.) in the module name
string.

Return value

If the function succeeds, the return value is a handle to the module.If the
function fails, the return value is NULL. To get extended error
information, call GetLastError.

Remarks

To enable or disable error messages displayed by the loader during DLL
loads, use the SetErrorMode function.LoadLibrary can be used to load a
library module into the address space of the process and return a handle
that can be used in GetProcAddress to get the address of a DLL
function. LoadLibrary can also be used to load other executable modules.
For example, the function can specify an .exe file to get a handle that can
be used in FindResource or LoadResource. However, do not use LoadLibrary to
run an .exe file. Instead, use the CreateProcess function.If the specified
module is a DLL that is not already loaded for the calling process, the
system calls the DLL's DllMain function with theDLL_PROCESS_ATTACH value.
If DllMain returns TRUE, LoadLibrary returns a handle to the module.
If DllMain returns FALSE, the system unloads the DLL from the process
address space and LoadLibrary returns NULL. It is not safe to
call LoadLibrary from DllMain. For more information, see the Remarks
section in DllMain.Module handles are not global or inheritable. A call
to LoadLibrary by one process does not produce a handle that another
process can use — for example, in calling GetProcAddress. The other process
must make its own call to LoadLibrary for the module before
calling GetProcAddress.If lpFileName does not include a path and there is
more than one loaded module with the same base name and extension, the
function returns a handle to the module that was loaded first.If no file
name extension is specified in the lpFileName parameter, the default
library extension .dll is appended. However, the file name string can
include a trailing point character (.) to indicate that the module name has
no extension. When no path is specified, the function searches for loaded
modules whose base name matches the base name of the module to be loaded.
If the name matches, the load succeeds. Otherwise, the function searches
for the file.The first directory searched is the directory containing the
image file used to create the calling process (for more information, see
theCreateProcess function). Doing this allows private dynamic-link library
(DLL) files associated with a process to be found without adding the
process's installed directory to the PATH environment variable. If a
relative path is specified, the entire relative path is appended to every
token in the DLL search path list. To load a module from a relative path
without searching any other path, use GetFullPathName to get a nonrelative
path and call LoadLibrary with the nonrelative path. For more information
on the DLL search order, see Dynamic-Link Library Search Order.The search
path can be altered using the SetDllDirectory function. This solution is
recommended instead of using SetCurrentDirectory or hard-coding the full
path to the DLL.If a path is specified and there is a redirection file for
the application, the function searches for the module in the application's
directory. If the module exists in the application's
directory, LoadLibrary ignores the specified path and loads the module from
the application's directory. If the module does not exist in the
application's directory, LoadLibrary loads the module from the specified
directory. For more information, see Dynamic Link Library Redirection.If
you call LoadLibrary with the name of an assembly without a path
specification and the assembly is listed in the system compatible manifest,
the call is automatically redirected to the side-by-side assembly.The
system maintains a per-process reference count on all loaded modules.
Calling LoadLibrary increments the reference count. Calling
the FreeLibrary or FreeLibraryAndExitThread function decrements the
reference count. The system unloads a module when its reference count
reaches zero or when the process terminates (regardless of the reference
count).Windows Server 2003 and Windows XP: The Visual C++ compiler
supports a syntax that enables you to declare thread-local
variables: _declspec(thread). If you use this syntax in a DLL, you will not
be able to load the DLL explicitly using LoadLibrary on versions of Windows
prior to Windows Vista. If your DLL will be loaded explicitly, you must use
the thread local storage functions instead of _declspec(thread). For an
example, see Using Thread Local Storage in a Dynamic Link Library.

Security Remarks

Do not use the SearchPath function to retrieve a path to a DLL for a
subsequent LoadLibrary call. The SearchPath function uses a different
search order than LoadLibrary and it does not use safe process search mode
unless this is explicitly enabled by
calling SetSearchPathMode withBASE_SEARCH_PATH_ENABLE_SAFE_SEARCHMODE.
Therefore, SearchPath is likely to first search the user's current working
directory for the specified DLL. If an attacker has copied a malicious
version of a DLL into the current working directory, the path retrieved
by SearchPath will point to the malicious DLL, which LoadLibrary will then
load.Do not make assumptions about the operating system version based on
a LoadLibrary call that searches for a DLL. If the application is running
in an environment where the DLL is legitimately not present but a malicious
version of the DLL is in the search path, the malicious version of the DLL
may be loaded. Instead, use the recommended techniques described in Getting
the System Version.

Examples

For an example, see Using Run-Time Dynamic Linking.

Requirements

Minimum supported clientWindows XP [desktop apps only]Minimum supported
serverWindows Server 2003 [desktop apps only]HeaderWinbase.h (include
Windows.h)LibraryKernel32.libDLLKernel32.dllUnicode and ANSI
namesLoadLibraryW (Unicode) and LoadLibraryA (ANSI)

See also

DllMainDynamic-Link Library
FunctionsFindResourceFreeLibraryGetProcAddressGetSystemDirectoryGetWindowsDirectoryLoadLibraryExLoadResourceRun-Time
Dynamic LinkingSetDllDirectorySetErrorMode


RemoveDllDirectory function

This topic has not yet been rated - Rate this topicRemoves a directory that
was added to the process DLL search path by using AddDllDirectory.

Syntax

C++ BOOL WINAPI RemoveDllDirectory( _In_ DLL_DIRECTORY_COOKIE Cookie );

Parameters

Cookie [in]The cookie returned by AddDllDirectory when the directory was
added to the search path.

Return value

If the function succeeds, the return value is nonzero.If the function
fails, the return value is zero. To get extended error information,
call GetLastError.

Remarks

After RemoveDllDirectory returns, the cookie is no longer valid and should
not be used.Windows 7, Windows Server 2008 R2, Windows Vista, and Windows
Server 2008: To call this function in an application, use
the GetProcAddress function to retrieve its address from
Kernel32.dll. KB2533623 must be installed on the target platform.

Requirements

Minimum supported clientWindows 8 [desktop apps only]Minimum supported
serverWindows Server 2012 [desktop apps only]VersionKB2533623 on Windows 7,
Windows Server 2008 R2, Windows Vista, and Windows
Server 2008HeaderLibLoaderAPI.h (include Windows.h);None on Windows 7,
Windows Server 2008 R2, Windows Vista, and Windows
Server 2008DLLKernel32.dll




DisableThreadLibraryCalls function

8 out of 8 rated this helpful - Rate this topicDisables the
DLL_THREAD_ATTACH and DLL_THREAD_DETACH notifications for the specified
dynamic-link library (DLL). This can reduce the size of the working set for
some applications.

Syntax

C++ BOOL WINAPI DisableThreadLibraryCalls( _In_ HMODULE hModule );

Parameters

hModule [in]A handle to the DLL module for which the DLL_THREAD_ATTACH and
DLL_THREAD_DETACH notifications are to be disabled.
TheLoadLibrary, LoadLibraryEx, or GetModuleHandle function returns this
handle. Note that you cannot call GetModuleHandle with NULL because this
returns the base address of the executable image, not the DLL image.

Return value

If the function succeeds, the return value is nonzero.If the function
fails, the return value is zero. The DisableThreadLibraryCalls function
fails if the DLL specified by hModule has active static thread local
storage, or if hModule is an invalid module handle. To get extended error
information, call GetLastError.

Remarks

The DisableThreadLibraryCalls function lets a DLL disable the
DLL_THREAD_ATTACH and DLL_THREAD_DETACH notification calls. This can be a
useful optimization for multithreaded applications that have many DLLs,
frequently create and delete threads, and whose DLLs do not need these
thread-level notifications of attachment/detachment. A remote procedure
call (RPC) server application is an example of such an application. In
these sorts of applications, DLL initialization routines often remain in
memory to service DLL_THREAD_ATTACH and DLL_THREAD_DETACH notifications. By
disabling the notifications, the DLL initialization code is not paged in
because a thread is created or deleted, thus reducing the size of the
application's working code set. To implement the optimization, modify a
DLL's DLL_PROCESS_ATTACH code to callDisableThreadLibraryCalls.Do not call
this function from a DLL that is linked to the static C run-time library
(CRT). The static CRT requires DLL_THREAD_ATTACH and DLL_THREAD_DETATCH
notifications to function properly.Windows Phone 8: This API is supported.

Requirements

Minimum supported clientWindows XP [desktop apps | Windows Store
apps]Minimum supported serverWindows Server 2003 [desktop apps | Windows
Store apps]HeaderWinbase.h (include
Windows.h)LibraryKernel32.libDLLKernel32.dll

See also

Dynamic-Link Library Entry-Point FunctionDynamic-Link Library
FunctionsFreeLibraryAndExitThread


★★★★★★☆☆☆☆☆☆★★★★★★☆☆☆☆☆☆★★★★



DN Blogs > David LeBlanc's Web Log > DLL Preloading Attacks

DLL Preloading Attacks

david_leblanc 20 Feb 2008 9:09 PM 2A DLL preloading attack is something
that can get you on a lot of different platforms. One of the first variants
I heard about was in an ancient telnet daemon on certain versions of UNIX
where you could specify environment variables, and one of the things you
could specify was where to look for libraries. Obviously, if you could get
the telnet daemon running as root to load your library, it was then your
system.A difference between UNIX-ish systems and systems based on DOS is
that the current directory "." is not on the search path for UNIX-ish
systems, and it is for DOS systems, which didn't have different users, so
there was no need to worry about some of these things. Originally, a
Windows system would look for DLLs using the same ordering that you'd look
for an executable – as documented in the SearchPath API:The directory from
which the application loaded. The current directory. The system directory.
Use the GetSystemDirectory function to get the path of this directory. The
16-bit system directory. There is no function that retrieves the path of
this directory, but it is searched. The Windows directory. Use the
GetWindowsDirectory function to get the path of this directory. The
directories that are listed in the PATH environment variable.The attack is
that you find some DLL an app needs, make an evil twin, and put it in the
same directory as a document, then lure someone who you'd like to have
running your code to open the document. This is obviously a problem, and
the advice we gave in Writing Secure Code (1&2) was to fully path the
library you wanted to access with LoadLibrary. This advice isn't always the
best, since if you weren't sure where you were installed, you might use
SearchPath to go find it, which looks in the current directory, and now you
have a problem again.What we did to fix it correctly was to make a setting
that moved the current directory into the search order immediately before
the path is searched, and after everything else. This took effect by
default in XP SP2, Win2k3 and later, and was available in Win2k SP4. For
the most part, this did get rid of the problem – if it was a DLL in the
operating system, that got searched well before the current directory and
all was good.Unfortunately, this isn't a complete fix in all cases – there
are some times that we'd like to test to see if a DLL is present, and then
do something special if it is. Even with the current directory moved to the
end of the search order, if it isn't there, we'll still look in the current
directory. So code that looks like this:hMod = LoadLibrary("Foo.dll"); //
check to see if Foo is presentWill be dangerous. You have a couple of good
options in dealing with this. If you never have a need to load a DLL from
the current directory, just call SetDllDirectory with an argument of "".
This is something I discovered by playing with the API, went and looked at
the code and found that it was an intended use of the function, logged a
bug, and now it's documented behavior you can depend on. If you can do
this, it's best – you don't have to put a lot of overhead around every
LoadLibrary call, and you're safe. The API is available in XP SP1 and
later, which is pretty safe as a minimum platform these days. A second
approach that would involve a bit of work on your part would be to
implement only the bits of SearchPath that you need. Here's what I'd
do:Search your app's directory – you can find this with GetModuleFileName
using NULL as the first parameter.Look in the system directory as aboveLook
in the Windows directory as aboveThere could be some wrinkles around
side-by-side DLL's, and I haven't looked closely at this aspect of the
problem – perhaps someone who has could comment. An option that I'd tend to
discourage would be to load the library with LOAD_LIBRARY_AS_DATAFILE as a
flag, then using GetModuleFileName to see if it is the one you wanted, or
checking somehow to see if it is the one you wanted using some form of
checksum. The first problem is that this is a lot of overhead, and the
second is that if there's a path to parse, odds are you'll do something
wrong and break when the format of the return changes, or you'll foul up
and make the wrong decision, since making decisions based on names is hard.
Checksums are easily defeated, and real cryptography is computationally
expensive.I've been meaning to write this for a while, as it's one of the
portions of Writing Secure Code that I'd like to update -




echNet Blogs > MSRC > Microsoft Security Advisory 2269637 ReleasedShare
Article1Connect to UsRSS for Posts@msftsecresponseSecurity NewsletterReport
a VulnerabilityTwC Blogs Windows Phone ApplicationGet on-the-go access to
the latest insights featured on our Trustworthy Computing blogs.Twitter
@msftsecresponse

Security Response

msftsecresponse

msftsecresponse Couldn't be there live? Q&A from yesterday's webcast
covering MS13-008 now posted at aka.ms/zylgj2 #MSFTSecWebcastyesterday
· reply · retweet · favoritemsftsecurity RT @HelpNetSecurity Looking
back at a year of #Microsoft patches. bit.ly/13xjSMO #InfoSecyesterday
· reply · retweet · favoritemsftsecresponse Join @jness &
@dustin_childsfor
a webcast discussing MS13-008 today at 1PM. Register at aka.ms/hdxbcu
#MSFTSecWebcast2
days ago · reply · retweet · favoritemsftsecresponse Time to apply
MS13-008, released today to address #Microsoft #SecurityAdvisory 2794220.
Details at aka.ms/gxv32y2 days ago · reply · retweet · favoriteJoin the
conversation

Microsoft Security Advisory 2269637 Released

MSRCTeam 21 Aug 2010 11:03 PMOverviewToday we released Microsoft Security
Advisory 2269637. This is different from other Microsoft Security
Advisories because it's not talking about specific vulnerabilities in
Microsoft products. Rather, this is our official guidance in response to
security research that has outlined a new, remote vector for a well-known
class of vulnerabilities, known as DLL preloading or "binary planting"
attacks. We are currently conducting a thorough investigation into how
this new vector may affect Microsoft products. As always, if we find this
issue affects any of our products, we will address them
appropriately.Additionally, today we are providing a defense-in-depth
update that customers can deploy that will help protect against attempts to
exploit vulnerable applications through this newly identified vector.
Finally, we are using our strong connections with researchers and partners
in the industry to help address this new class of vulnerability. Our
Microsoft Vulnerability Research program has been working to coordinate
communication between the researcher who first brought this new vector to
us and other application developers who are affected by this
issue.Technical BackgroundWhat this new research demonstrates is a new
remote vector for DLL preloading attacks. These attacks are not new or
unique to the Windows platform. For instance, PATH attacks that are similar
to this issue constitute some of the earliest class of attacks against the
UNIX operating system. The attack focuses on tricking an application into
loading a malicious library when it thinks it's loading a trusted library.
For this to succeed, the application has to call the trusted library by
name instead of properly using its full path (for example, calling
dllname.dll rather than C:\Program Files\Common Files\Contoso\dllname.dll).
The attacker then has to place a malicious copy of the library in a
directory that the system will search to locate the library and have that
be a directory it will search before the directory where the trusted
library actually is. For example, if an attacker knows that the application
simply calls for dllname.dll (rather than using the full path) and it will
look for dllname.dll in the current working directory before looking in
C:\Program Files\Common Files\Contoso\. Then if the attacker can plant a
malicious copy of dllname.dll in the current working directory, the
application will load it first executing the attacker's code in the
application's security context.PATH or DLL preloading attacks have so far
required the attacker to plant the malicious library on the local client
system. This new research outlines a way an attacker could levy these
attacks by planting the malicious library on a network share. In this
scenario, the attacker would create a data file that the vulnerable
application would open, create a malicious library that the vulnerable
application would use, post both of them on a network share that the user
could access, and convince the user to open the data file. At that point,
the application would load the malicious library and the attacker's code
would execute on the user's system.Because this is a new vector, rather
than a new class of vulnerability, the existing best practices that protect
against this class of vulnerability, automatically protect against this new
vector: ensuring that applications make calls to trusted libraries using
full path names.While the best protection is following best practices, we
are able to provide an additional layer of defense by offering a tool that
can be configured to disable the loading of libraries from network shares.
In particular, because this is altering functionality, we encourage
customers to evaluate this tool before deploying it. As part of your
evaluation, we encourage you to review the information at the Security
Research and Defense (SRD) blog.We will continue our work with the
researchers and the industry to identify and address vulnerable
applications. And as always, we will update you with any new information we
have through our security advisories, security bulletins and the MSRC
weblog as appropriate




an we load library with lower privilege level ?

As LoadLibrary call loads the dll with equal privilage as of caller
process. For example if process from admin rights loads the dll, the dll
gets the access right of admin level.So is there any way so that one can
load dll by providing it a lower privilege level.Taj_Sengar9/28/2011

good to use SetSearchPathMode() even if you don't use SearchPath()

Some Windows APIs follow the "do not use" practice of using SearchPath()
and passing the result to LoadLibrary() (e.g., CryptAcquireContext() on XP,
or ExtractIconEx() on XP through Win7) so you may want to call
SetSearchPathMode() to avoid this potential source of issue even if your
own code avoids this behavior.md128/23/2011

PATH Environment Variable

It might also be a good idea to remove the PATH-Environment-Variable from
the process:SetEnvironmentVariable(TEXT("PATH"),NULL);geeky









☆☆☆☆☆☆☆♡♡♡♡♡♡☆☆☆☆☆☆♡♡♡♡♡♡♡♡♡♡♡☆☆☆☆☆☆☆



















♥♥♥♥♡♡♡♡☆☆☆☆☆★★★★★★☆♡♡♡♡♡☆☆☆♥♥♥♥♥♥♥♥






















☆☆☆☆☆★★★★★★☆☆☆☆☆☆★★★★☆★☆☆☆☆☆☆☆