Almost a year later... but is this issue resolved?   
   =================================================   
      
      
   Path: news.grc.com!.   
   Newsgroups: grc.news.latestversions,grc.security   
   Subject: DLL search order vulnerability   
   Date: Sun, 29 Aug 2010 14:32:30 -0700   
      
   About the recent MS article:   
   ----------------------------   
   http://support.microsoft.com/kb/2264107   
   The workaround presented here is not a patch, and can break some applications,   
   namely Microsoft Outlook and Google Chrome, according to commenters on the   
   SANS piece below.   
   http://isc.sans.edu/diary.html?storyid=9445   
      
      
   ---------------------------   
   About the DLL search order:   
   ---------------------------   
   If a DLL is called from an application, and it is not called explicitly called   
   (full path to the DLL), then Windows searches a series of location until it   
   finds a file with a matching name.   
   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   
      
   Programs that call a DLL with a complete path to the file avoid the search   
   order issue, and are not vulnerable to this exploit.   
      
   Programs that do not use a complete path to the DLL are at risk especially if   
   the DLL being called is not a standard Windows DLL found in the first 4   
   locations above.   
      
      
   ------------------------------------   
   Contributary factors in the exploit:   
   ------------------------------------   
   1. Data files are associated with specific applications by the file extension.   
   2. File extensions are hidden by default in Windows.   
   3. DLL files are hidden by default in Windows.   
      
      
   -------------------------------------------------------------   
   The current working directory (CWD) and associated datafiles:   
   -------------------------------------------------------------   
   This is the crux of the issue.   
   By double-clicking a data file from some location (a local directory, network   
   directory, removable media, etc), the associated application is launched with   
   the CWD being the directory containing the datafile.  If that directory also   
   contains a DLL that has the same name as one called by the application, and   
   that DLL is not found in the first 4 locations, the DLL can be loaded from the   
   directory containing the datafile, the CWD.   
      
      
   -----------------------------------------------------   
   The Microsoft work-around and Microsoft Outlook 2003:   
   -----------------------------------------------------   
   One of the folks who posted comments on the SANS article above determined that   
   Microsoft Outlook does something rather bizarre when it loads.  It changes its   
   CWD to a directory under "C:\Program Files\Common Files\System" in order to   
   load MSMAPI32.DLL.   
   Consequently applying the Microsoft work-around to fix the vulnerability   
   causes Outlook to fail loading the MSMAPI32 DLL.   
      
      
   ------------------------------------------------------------   
   Flash drives, network drives, and ZIP files most vulnerable:   
   ------------------------------------------------------------   
   Though YOUR COMPUTER may be virus-free and fully patched, if you open a   
   datafile associated with one of the vulnerable applications, YOUR computer is   
   at risk of loading malicious code.   
      
   If someone you know gives you a flash drive that they've used in their   
   compromised computer (but they are unaware their computer is infected), and it   
   contains a datafile (which is clean) and the DLL (hidden by Windows by   
   default), then despite your computer being clean, when you double-click the   
   datafile, your application will load the malicious DLL from the USB flash   
   drive.   
      
   A similar scenario - actually much worse - applies to a large business   
   network.  If the malware was sophisticated enough, it would look for existing   
   PPTX (Power Point 2007 is one of the affected applications) files on network   
   shares and only place the boobytrapped DLL in the same folder as the PPTX   
   files.  Nothing would even look out of place to other network users when   
   exploring the folder.  All it takes to get the whole network full of these   
   DLLs is one employee with an infected USB stick or laptop.   
      
   And, because Microsoft treats ZIP files as "folders", then packaging a benign   
   datafile and a malicious DLL in the same ZIP file would have the same result   
   as that of a flash drive or a network drive.  The ZIP file would be treated as   
   the CWD, current working directory.   
      
   --    
   http://www.infoworld.com/t/anti-virus/how-thwart-the-new-dll-hijacks-539   
   "How to thwart the new DLL hijacks"   
      
   The main recommendation in the InfoWorld is to drag all datafiles to your   
   Windows "desktop" (or otherwise "known clean", free of rogue DLLs, location)   
   before opening them.  I'm not sure how practical this is for most folks,   
   particularly business networks.  Still, the tip should work.   
      
   -----------   
   Conclusion:   
   -----------   
   This could be a big problem until all the individual apps are fixed.   
      
   --- Thunderbird 2.0.0.24 (Windows/20100228)   
    * Origin: Fidonet Via Newsreader - http://www.easternstar.info (1:123/789)