Message-ID: <B4C7EC28EDFD4D7F80CFE1FACE140610@W340>
Date: Fri, 15 Jan 2016 16:18:26 +0100
From: "Stefan Kanthak" <stefan.kanthak@...go.de>
To: <bugtraq@...urityfocus.com>
Cc: <fulldisclosure@...lists.org>
Subject: Defense in depth -- the Microsoft way (part 38): does Microsoft follow their own security guidance/advisories?

Hi @ll,

in 2009/2010, after beeing hit by "carpet bombing" and "binary
planting" alias "DLL hijacking/spoofing/preloading" (see
<https://blogs.technet.com/b/srd/archive/2009/04/14/ms09-014-addressing-the-safari-carpet-bomb-vulnerability.aspx>
and <https://technet.microsoft.com/en-us/library/2269637.aspx>)
Microsoft finally started to provide security guidance/advisories
for "safe library loading" to Windows developers:

<https://msdn.microsoft.com/en-us/library/ms682586.aspx>

| Applications can control the location from which a DLL is loaded by
| specifying a full path or using another mechanism such as a manifest.

<https://msdn.microsoft.com/en-us/library/ff919712.aspx>

| Wherever possible, specify a fully qualified path when using the
| LoadLibrary, LoadLibraryEx [...] functions.

<http://blogs.technet.com/b/srd/archive/2010/08/23/more-information-about-dll-preloading-remote-attack-vector.aspx>

| When an application loads a DLL without specifying a fully
| qualified path name, Windows will attempt to locate the DLL by
| searching a defined set of directories.
...
| Development best practices state that applications should call
| SetDllDirectory with a blank path before calling
| LoadLibrary("foo.dll") to ensure that foo.dll is not loaded from
| the current directory. We are investigating whether any of our
| own applications are affected by this class of vulnerability so
| that we can take appropriate action to protect customers.

<https://support.microsoft.com/en-us/kb/2389418>

| Use fully qualified paths for all calls to LoadLibrary, [...]
| where you can.

<https://technet.microsoft.com/en-us/library/2269637.aspx>

| This exploit may occur when applications do not directly specify
| the fully qualified path to a library it intends to load.

<https://blogs.technet.com/b/srd/archive/2014/05/13/load-library-safely.aspx>

| Always specify the fully qualified path when the library location
| is constant.


Now the (obviously rhetorical) question: does Microsoft follow their
own guidance?

The (also obvious) answer: THEY DON'T, at least for existing code,
despite "trustworty computing" or the "secure development lifecycle"
Microsoft brags about since years.


Some examples for unsafe library loading recently published:

FEClient.dll (see CVE-2016-0014 and MS16-007):
  introduced in Windows 2000, loaded without fully qualified path
  by AdvAPI32.dll since then.

  FEClient.dll is loaded from the "application directory" of every
  program which uses EFS functions (see
  <https://technet.microsoft.com/en-us/library/cc781588.aspx>
  and <https://msdn.microsoft.com/en-us/library/ms995356.aspx>):
  all executable installers and self-extractors used by Microsoft
  allow^Wsupport "DLL hijacking" via FEClient.dll!


OCIW32.dll, OCI.dll (see MS15-132):
  loaded without fully qualified path by MSDAORA.DLL since Windows NT4.


ELSEXT.dll (see MS15-132):
  loaded without fully qualified path by ELS.DLL since Windows Vista.


MQRT.dll (see MS15-132):
  loaded without fully qualified path by COMSVCS.DLL since Windows NT4.


EDBBCli.dll, ESEBCli2.dll (see MSKB275876):
  loaded without fully qualified path by NTBackup.exe since Windows NT4.

  Mitigation:
  ~~~~~~~~~~~

  [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\NTBackup.exe]
  "CWDIllegalInDLLSearch"=dword:ffffffff

  [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\BackupRestore\DLLPaths]
  "EDBBCli"="C:\\Windows\\System32\\Kernel32.Dll"
  "ESEBCli2"="C:\\Windows\\System32\\Kernel32.Dll"


UXTheme.dll (see CVE-2012-4206, ...):
  introduced in Windows XP, loaded without fully qualified path by
  AppWiz.cpl, BrowseUI.dll, ComDlg32.dll, Dot3UI.dll, DUser.dll,
  Explorer.exe, HelpCtr.exe, Kernel32.dll, LogonUI.exe, MMC.exe,
  MSHTML.dll, Shell32.dll, ShlWAPI.dll, ThemeUI.dll, WSCUI.dll,
  WZCDlg.dll and MANY more since then.

  Almost all executables using the Windows GUI allow^Wsupport
  "DLL hijacking" via UXTheme.dll.

  Mitigation: 
  ~~~~~~~~~~~

  use SAFER alias Software Restriction Policies and deny execution
  everywhere except %SystemRoot% and below and %ProgramFiles% and
  below.

  See <http://home.arcor.de/skanthak/SAFER.html> and/or
  <http://mechbgon.com/srp/index.html> for instructions.


stay tuned
Stefan Kanthak

Powered by blists - more mailing lists