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)