Windows Format command allows DLL loading abuse

Gandalf_The_Grey

Level 62
Thread author
Verified
Helper
Top poster
Content Creator
Well-known
Apr 24, 2016
5,110
It is almost unbelievable what can be hidden behind Windows functions and commands. The format command for formatting disks, which has been available in the command prompt for ages, has a side effect. With a parameter the call of an arbitrary DLL can be forced, which is then loaded from the search path. I could hardly believe this when it was brought to my attention.

The facts came to my attention from Grzegorz Tworek on Twitter in a short post. The statement in the following tweet is: If you specify the name of any DLLs with a preceding letter U at the parameter /FS in the command line, the DLL is loaded from the search path.

The DOS format command allows various parameters which are described in this Microsoft document. With the switch /FS:filesystem the desired file system can be specified. According to Microsoft, the following file systems can be specified for formatting via the switch: FAT, FAT32, NTFS, exFAT, ReFS, or UDF.

Grzegorz Tworek has now noticed that there is an undocumented possibility, over which theoretically arbitrary file systems can be used when formatting. Only an appropriate DLL must be present, which takes over the formatting. As parameter for /FS then the name of this DLL with a prefix U is to be indicated. A command line of the type:

format I: /fs:UMyDll.dll

would then load the library file MyDll.dll and cause it to be listed. This DLL is then executed in the search path, i.e. the program folder and other folders. Grzegorz Tworek has demonstrated this on his own DLL called Pwning.dll, which then displays a message box with the word Pwned! There are certainly a few ways in which this can be abused.
 
F

ForgottenSeer 92963

To prevent DLL-hijacking copy text below ___ to notepad (or any other text editor)and save as SafeDLLSearchMode.reg and run (is a recommended hardening tweak for DLL-hijacks in general)

____

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager]
"SafeDllSearchMode"=dword:00000001
 
Last edited by a moderator:

Andy Ful

From Hard_Configurator Tools
Verified
Helper
Top poster
Developer
Well-known
Dec 23, 2014
7,073
SafeDLLSearchMode is enabled by default since Windows Vista and cannot prevent the current DLL hijacking methods.

Standard Search Order for Desktop Applications​

The standard DLL search order used by the system depends on whether safe DLL search mode is enabled or disabled. Safe DLL search mode places the user's current directory later in the search order.

Safe DLL search mode is enabled by default. To disable this feature, create the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\SafeDllSearchMode registry value and set it to 0. Calling the SetDllDirectory function effectively disables SafeDllSearchMode while the specified directory is in the search path and changes the search order as described in this topic.

If SafeDllSearchMode is enabled, the search order is as follows:

  1. The directory from which the application loaded.
  2. The system directory. Use the GetSystemDirectory function to get the path of this directory.
  3. The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched.
  4. The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
  5. The current directory.
  6. The directories that are listed in the PATH environment variable. Note that this does not include the per-application path specified by the App Paths registry key. The App Paths key is not used when computing the DLL search path.


Most DLL hijacking methods will use the directory from which the application is loaded (point 1) and not from the current directory (point 5).

Edit.
More precisely, Safe DLL search mode is enabled by default starting with Windows XP with Service Pack 2.
https://docs.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-security
 
Last edited: