Microsoft Should Formally Deprecate CWD from LoadLibrary Search

Microsoft recently released security security advisory 2269637, “Insecure Library Loading Could Allow Remote Code Execution”. The gist is that the search behavior of LoadLibrary() includes the current working directory, which is not the same as the directory containing the binary executable. Typically the current working directory (CWD) is set at launch time by Windows shell shortcut (LNK) or implicitly by invoking a document with a file association. The CWD can be anywhere on a supported local or remote file system, including Windows network (SMB/CIFS) shares and WebDAV.

Most applications must load code from libraries (DLLs) in order to run. The CWD is not a trusted secure location like Program Files or System32 but for reasons of backwards compatibility with pre-Windows NT forms of Windows, CWD is searched when loading DLLs. This makes the default behavior of LoadLibrary() dangerous and many, many Windows applications are vulnerable to luring attacks as a result.

Sample Luring Attack Scenario

  • Click on a link to an MP3 in an email or web page
  • File association causes popular MP3 player to load
  • CWD is set to the remote location of the MP3 player
  • Attacker has placed a malicious DLL that the popular MP3 player loads in the same location as the MP3
  • MP3 player loads malicious DLL
  • Malicious DLL loads the real DLL so MP3 player won’t crash
  • Popular MP3 player is owned an executing evil code

    Unfortunate Default Behavior

    Your application doesn’t have to search CWD but it is the default for reasons of backwards compatibility. Developers can turn this behavior off but it is the default and you a) have to know that you need to turn it off and b) know how to turn it off.

Patch Optionally Introduces New Behavior

KB2264107 is a patch that allows you to set registry keys to change the circumstances under which CWD is considered. The simplest option is to create a new DWORD value of the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager key called CWDIllegalInDllSearch and set it to 0xffffffff. chrome-load-dll-cwd-errorThis globally disables the use of CWD for loading libraries.

My first thought was this would be fine. I’m running Windows 7 x64 with no legacy 16-bit apps. It should work fine and for me it did. The second computer I tried this on had a problem where Google Chrome 5 was unable to find avutil-50.dll. Chrome keeps its DLLs in a version-numbered subdirectory of the one containing Chrome.exe. This isn’t a part of the normal DLL search path and it seems like Chrome 5 is working around this by setting CWD to the directory which contains the DLLs before calling LoadLibrary(). Chrome 6 beta doesn’t do this which is why I didn’t notice the problem.

To fix this you can either dial the global CWDIllegalInDllSearch down to 2 which indicates CWD is allowed to be searched only if it is a local folder. Better, is to create a KEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\chrome.exe key with a CWDIllegalInDllSearch DWORD value of 2 (and remember to delete this when Chrome 6 goes stable).

I had a similar problem with the Apple Update program failing when it tried to install the latest version of QuickTime.

Developers Should Disable Loading DLLs from CWD

depI was really stunned to realize that Chrome was using this CWD load behavior. They probably didn’t realize the implications and it is insidious because it is the default. I think all developers and testers should install KB2264107 and globally disable loading from CWD. (Yes this is a PITA and it might break stuff on your box but you can suck it up and white list apps that are broken.) If your apps are broken by this then you need to fix them.

Microsoft should encourage this by formally deprecating loading DLLs from CWD with Windows 7 SP1. They need to roll it out like they did DEP. There needs to be Group Policy settings and a GUI for manipulating these registry keys along the lines of the DEP compatibility with radio buttons like “Turn on loading libraries from CWD” and “Turn off loading libraries from CWD except for those I select". With Windows 7 SP1, the default is to leave CWD turned on. By the time Windows 8 rolls around, the default is to disable CWD.

KB2264107 is Insufficient

The hotfix should probably actually provide some protection by globally disabling some form of CWD loading. Right now all it does is create the potential for you to make some registry changes which is definitely not OK for the average user. At a minimum they need to disable CWD over WebDAV (CWDIllegalInDllSearch=1) and probably all network shares (CWDIllegalInDllSearch=2). I’m curious why there is no setting to disable CWD on removable media like USB keys without cranking CWDIllegalInDllSearch all the way to 0xffffffff and disabling CWD globally.

Microsoft needs to provide a GUI and a Group Policy for managing the keys for disabling loading libraries from CWD. The Group Policy option is critical for Enterprise so that they can keep legacy apps running which can’t be modified. They also need to make it clear that loading from CWD is going to be deprecated very soon and will no longer be the default behavior in the next version of Windows.

Microsoft should also provide guidance that any app which depends on loading libraries from CWD is vulnerable. In particular, legacy line of business apps which cannot be made to run without loading libraries from CWD should not be allowed to run on a computer with network access because such apps will be juicy targets for spear phishing. In a lot of cases it should be possible to fix apps that load libraries from CWD by just moving the DLLs into the same directory as the EXE. If the app can’t be fixed, it needs to be sandboxed from the network.

Mitigate Adobe Reader Vulnerabilities with Google Chrome PDF Viewer

Adobe Reader has a growing list of exploits and a current unpatched vulnerability. The crux of the problem is that PDF documents are not simply documents. PDFs can contain arbitrary code in the form of Javascript or Flash as Adobe Reader embeds a full Javascript runtime and a private Flash runtime environment. Javascript can be disabled via the options but the Flash engine cannot be disabled via the GUI.

An interesting development is that Google Chrome 6.x includes its own PDF rendering plugin. This plugin converts PDF to HTML5 and renders it with the webkit engine. It is very fast and a fundamentally different approach from Adobe Reader. Commodity attacks on Adobe Reader should not be effective on Chrome.

The Chrome Beta channel includes the Chrome PDF viewer plug-in but it is disabled by default. Go to the about:plugins page to enable it. You can also disable the Adobe Reader plug-in while you are at it.


Dogpile on RIM

RIM caved to pressure from Saudi Arabia and will be installing servers there that can be monitored by Saudi authorities. Now, India has given RIM until August 31 to make a similar concession or have service suspended. I’m sure RIM will capitulate in order to stay in business. This is an unhappy precedent.

India is apparently also threatening to shut down Google and Skype messaging services unless the Indian government has the ability to intercept and monitor traffic.

Clearly, we need ubiquitous, secure and easy-to-use peer-to-peer cryptography so that governments have no central actors to put pressure on. Maybe the solution is OpenPGP but it needs to be much easier for people to use.

Mossad Used Blackberries During Assassination?

Some back story on the decision of UAE to ban Blackberry data service. It may be that the Mossad used pre-paid Blackberry handsets to communicate securely while when it assassinated Hamas operative Mahmoud al Mabhouh in a Dubai hotel last January.


Gulf Arab States to Block Blackberry

UAE and Saudi Arabia are set to block Blackberry email service because it is too secure. Both nations are unhappy that they can’t read email sent via the Blackberry device because all of the messages are encrypted and transferred to RIM servers in Canada for delivery. If the recipient is also a Blackberry, the message transfer is encrypted end-to-end. Thus, no snooping. There are close to a million Blackbery users collectively in UAE and Saudi and their devices are about to stop working.

But what is the point? This is simply an inconvenience to legitimate users and unlikely to yield any security benefit because there is nothing to stop people from using web-based email encrypted over SSL (like gmail) or other smart phones such as Android and iPhone which supported transport layer security ensuring that nobody is snooping on the message traffic to the server.

Also, unless they plan to block all Blackberry data service, there is nothing stopping Blackberry users from using a non-RIM email app like the gmail app for Blackberry or RIM’s gmail plugin.

Is Dubia really planning to disable all Blackberry mail service in October? How does that gibe with their desire to be an international business hub?

I’m left scratching my head because this seems totally irrational.


It seems UAE is taking a much harder line on this. They are planning to block all data service to the Blackberry handset. Saudi is only interested in blocking the Blackberry Messenger encrypted Blackberry-to-Blackberry instant messaging. UAE and Saudi claim that they are worried about intercepting terrorist communications but all of these measures are wrong-headed solutions that punish legitimate users. They don’t stop terrorists from moving on to the next technology but they do disrupt business which is not so agile. In this case it seems that all other smart phones besides Blackberry are fine including those that use Microsoft’s ActiveSync which is fundamentally HTTP data encrypted over an SSL channel are permitted. That includes Microsoft Exchange-based and Google Apps services and iPhone OS/iOS, Android and Windows –based handsets.

Run Process Explorer x64 LUA from Program Files without UAC prompts

procexpProcess Explorer by Mark Russinovich is a great improvement over the Task Manager program that ships with Windows. It give a ton of information about processes running on your computer. It keeps presents a full range of stats on every process including memory consumption and CPU time, loaded DLLs and open handle, strings embedded in the binary, environmental variables defined for the process, the full arguments used to start the process and nifty tools to find a process or a handle and a handy restart process. It is a great aid to debugging. ProcExp has some quirks when running on x64 Windows, though.

I have run my workstation as a “User” without admin rights for over 12 years since the days when I started running NT4 on my laptop. I used to have to log out and log in as an “Administrator” to install software or make system changes. There were tweaks you could make to dial back the security for some little things like creating a security role that could change the system date and time (which allows you to open the old-style date and time applet by clicking on the taskbar clock). With Windows 2000, things got a lot better with the runas service (like su(1) on UNIX)  but there were still some painful quirks because, for example, some software expects to be installed by the same admin user account that is using it. That’s where Aaron Margolis’s excellent makemeadmin script comes in. And finally with Windows Vista, we get UAC which, is nothing more than a speedbump warning system if you are an Administrator. However, if you are a non-Admin user it is a graphical just-in-time way to change the security of a running process by giving it Administrator credentials.

One of the main advantages of running with a limited user account (LUA) is that binaries in Program Files where they are protected from tampering by something malicious that you might accidentally invoke. For example, if you got hit with a zero-day browser flaw the worst (and this is very bad) thing that can happen is to have your personal data stolen or corrupted. The system itself cannot be subverted. Rogue usermode binaries cannot be installed and neither can drivers be installed. Hence, you cannot become part of a botnet and this is a very good thing.

Furthermore, most commodity attacks for Windows go straight for installing a rootkit without passing Go. That means instead of doing something bad to you that could succeed they try to do something worse that can’t and they crash doing nothing. That’s not a promise, just a generalization. AppLocker is what you need to take LUA to the next level to prevent unauthorized code from executing at all.

Anyway… Enough back story. Suffice it to say that I run my system without administrative rights and I don’t want to be typing in my admin credentials unless actually necessary.

The problem is that the x64 version of Process Explorer is embedded inside of the 32-bit version. When you invoke the 32-bit version of ProcExp on x64 Windows, procexp.exe extracts procexp64.exe into the same directory where it is currently running and starts procexp64.exe. If you have your Sysinternals tools in Program Files then in Vista or later with UAC turned on this generates a UAC prompt because procexp.exe is trying to write to the protected Program Files directory tree. (On Windows Server 2003 x64 or Windows XP x64 you get an access denied.) After procex64.exe exits the file is deleted.

ProcExp can actually run just fine without elevated permissions unless you need process details for a service or some other process running with another user’s credentials and procexp has a way to elevate itself to deal with that scenario, just like Task Manager.

Here is the trick to get procexp working LUA in Program Files on x64:

  • Download the procexp ZIP archive from Technet
  • Extract the ZIP file somewhere and run procexp.exe
  • Accept the license prompt
  • Make a copy of procexp64.exe (CTRL+C, CTRL+V will suffice)
  • Exit procexp.exe.
  • Delete procexp.exe.
  • Rename your copy of procexp64.exe to procexp.exe
  • Copy procexp.exe to your Sysinternals folder in “C:\Program Files”

Mark Russinovich could also solve this issue to either releasing a standalone x64 binary of procexp or changing the behavior of the extraction so that procexp64.exe doesn’t get deleted on exit (meaning you would just elevate once). In the mean time, the workaround isn’t too painful.

Online Billing Scary Error

I went to my Vodafone Ghana online billing login and got a big fat scary error:


The SSL certificate is expired. It expired over a month ago:


Now, there’s really not much of a problem here. The certificate is perfectly able to encrypt my connection to the server and it identifies the server as belonging to It’s just out of date. Embarrassing for Vodafone but it is actually safe for me to continue.

This is exactly the sort of wolf-crying that teaches people to ignore security warnings that computers throw up. To a normal human that just wants to complete a task, the big red screen looks an awful lot like “Blah, blah, blah, click the ‘Proceed’ button if you want to get your bills paid.”

Cormac Herly has a great paper on the rational rejection of security advice by users where he notes that “fully 100% of certificate error warnings appear to be false positives.” The gist of Herley’s argument is that burdens of understanding and implementing good e-security may not be worth it to people in a rational cost-benefit trade off of the perceived risk versus the value of their time and pain.

Mitigate Stuxnet with Least Privilege and AppLocker

There is a lot of concern about the LNK (shortcut) vulnerability which exists in all current versions of Windows. Basically, viewing a malicious link file or favicon in a web site will cause Windows to execute the malicious code which can be hosted remotely on an SMB network or a WebDAV server on the Internet.The vulnerability is actively being exploited by very sophisticated bad guys and there is no patch available, yet.

So what can be done to mitigate the risk in lieu of a patch?

Microsoft has a “Fixit” solution that involves disabling Windows’ ability to load icons resources on shortcuts. This solution basically makes Windows unusable because all icons in the Start menu and task bar become generic white documents.

The other recommendation is disabling the WebClient service but this breaks integration with Sharepoint and other services based on WebDAV.

I’m not sure why it isn’t being recommended by Microsoft but the AppLocker feature of Windows 7 should provide a robust mitigation without these side-effects.

AppLocker is a policy technology which allows an administrator to define which executables are allowed to run on a computer. The rules can be based on a any combination of trusted paths, file names and cryptographic hashes of files.

Least Privilege

The first step, though is to make sure that your day-to-day account is not anadministrators Administrator. UAC is not really a security boundary. If you are an Administrator it is a warning system to be careful but nothing more. If you are a non-administrator it works to elevate your rights to perform administrative tasks. If your account is in the Administrators group, create another account or enable the built-in Administrator account and remove yourself from the Administrators group.

For example, my main system—which is not joined to a domain—has only the Administrator in the Administrators group. (Be sure to create yourself an administrator account before removing your main account from Administrators or you will lock yourself out of your machine.)

Without Administrator-level privileges, most worms—including the Stuxnet worm exploiting the Windows LNK vulnerability—will fail to deliver its payload. That’s because they usually try to install a rootkit which means installing drivers which requires Administrator privileges. If you don’t have those privileges, the OS can’t be compromised.

Trusted Apps with AppLocker

As worms become more sophisticated, they may find ways to do their work without requiring Administrator privilege. Certainly, Administrator privilege isn’t required in order to steal your personal data because your account has access to personal data. This is where AppLocker comes in. AppLocker creates a concept of trusted applications. Only trusted applications are allowed to run. The default ruleset is pretty good. It simply says that normal users can only execute programs in the Windows directory or the Program Files directory. Those directories have permissions set on them so that only Administrators can put files in there. Hence the applications installed there are trusted.

In order to configure AppLocker, you first need to start the “Application Identity” service and set it to start automatically.

Next use the local security policy editor to configure AppLocker. If you are running as a non-admin, the command-line is this:

runas /user:Administrator "mmc secpol.msc"

Or you can search for “Local Security Policy”, right-click and choose Run as Administrator from the menu. (If you are running as a non-admin, you have to provide a password or smart card for the administrator-level account.)create-default-rules

Navigate to Security Settings | Application Control Policies | AppLocker | Executable Rules. Right-click on Create Default Rules. AppLocker will generate the reasonable set of defaults that I described above.

Unfortunately a few useful application don’t install themselves in Program Files. For example, Google Chrome installed itself on a per-user basis in the application data folder structure of each user. I believe the primary reason it does this is to be able to silently update itself on a least-privilege machine. It also makes it possible for users to install in an enterprise environment where users don’t have administrator privileges. With the default AppLocker settings, Chrome will be blocked from running.

If you want to run Chrome, the simplest solution is to trust the Google signing key and allow any applications published by Google to run.

Right-click on Executable Rules. Choose Create New Rule… Click “Next” through all the screens until you get to the screen asking to browse for an executable. For this purpose, any binary signed by Google will do but I’m going to use chrome.exe. For me, chrome.exe lives in


After selecting Chrome.exe, slide the selector up to Publisher and click next until you are allowed to choose create.


Now we are trusting Google not to let someone steal their signing certificate and do something bad with it. Chrome runs and so do any other executables signed by Google.

Also, anything installed in C:\Program Files or C:\Program Files (x86) or C:\Windows runs.

Windows won’t let any other executables run.

This should posture completely mitigate the Stuxnet attacks because no untrusted code is ever allowed to run.


AppLocker creates a problem for developers that want to run as a limited-rights user. They won’t be able to execute and debug binaries that they compile!

This problem should primarily affect people creating directly executable code. Dynamic code (perl, python, ruby, vbscript, powerhsell script, etc.) executed by a trusted interpreter will work as will Java class and jar files because they are executed by java.exe or javaw.exe.

The issue is really directly executable Portable Executable (PE) binaries. It doesn’t matter if they are native or managed binaries. AppLocker won’t let them run.

The solution is straightforward. You have to relax the policy enough so that developers can work. The risk is that developers will execute stuff that they shouldn’t or some malware will leverage the knowledge of the location of the developer sandbox. It’s a risk you have to accept.

Put all of your source code into a directory tree and create a rule in AppLocker to allow any executables in there to run. For example, you could create a Developers security group and a “C:\source\*” directory. Grant Administrators and System “Full Control” and grant Developers “Modify” on C:\Source. In AppLocker grant Developers the right to execute on “C:\Source\*”.


Unfortunately the biggest limitation is that AppLocker is only available in Windows 7 Enterprise and Ultimate or any version of Windows Server 2008 R2.


Amazon Kindle for PC also installs itself into %localappdata%. Cisco’s WebEx installs itself onto the “all users” application data directory (%allusersprofile%). They need AppLocker publisher exlusions in order to run.

Sandboxing Flash with Chrome

Perhaps the most brilliant feature of Google’s Chrome browser is that it installs itself without any admin rights required inside each user’s profile directory. The first important consequence of this is that Chrome can go viral inside of corporate departments officially standardized on IE6 because it doesn’t require any tech savvy to install Chrome outside of the protected “Program Files” directories. The second consequence is that, since the user always has full permissions to its install directories, Chrome can and does silently and continuously update itself.

The updating works extremely well. It happens quietly in the background. After an update has occurred, the next time Chrome is started it is the new version. Chrome does have security bugs, but it uses Integrity levels to sandbox itself and patches are continuously and silently rolled out which keeps the browser safe.


Recently Chrome started distributing its own private copy of Adobe Flash. That means that Google believe that Flash is necessary. Since Flash is necessary, Chrome will always have the latest version of Flash and it will be silently updated along with Chrome itself. For all other browsers, there is no automatic update process for Flash. The standard ActiveX installation process for IE is painful and failure prone. For this reason alone, Chrome distributing its own Flash is great but since Flash is also riddled with security problems, this is a huge win.

Adobe seems to be happy with this Google-love, especially since they are being flamed publically and repeatedly by Steve Jobs. It is interesting but I think what is really going on is that Google recognizes that if Flash doesn’t work right or you get a malware while using their Chrome, Google takes the blame.

Whatever the motivation, it is a win. I’m ready to let Chrome handle updating my Flash and stop wasting my time worrying about whether I have the current version and whether it is safe. In fact, I can’t think of a good reason to have Flash floating around on my system as a global service outside of its Chrome sandbox.

Adobe provides a tool to globally uninstall Flash which removes both the ActiveX and Netscape-compatible plug-in versions but leaves Chrome’s private Flash runtime untouched.


Bruce Schneier: U.S. enables Chinese hacking of Google

Notable cryptographer and security expert Bruce Schneier has a new essay up at CNN.

In order to comply with government search warrants on user data,Google created a backdoor access system into Gmail accounts. This feature is what the Chinese hackers exploited to gain access.

This problem isn’t going away. Every year brings more Internet censorship and control, not just in countries like China and Iran but in the U.S., the U.K., Canada and other free countries, egged on by both law enforcement trying to catch terrorists, child pornographers and other criminals and by media companies trying to stop file sharers.

The problem is that such control makes us all less safe. Whether the eavesdroppers are the good guys or the bad guys, these systems put us all at greater risk. Communications systems that have no inherent eavesdropping capabilities are more secure than systems with those capabilities built in. And it’s bad civic hygiene to build technologies that could someday be used to facilitate a police state.

Read the entire article at This essay is a follow-up to a previous Schneier essay, “Technology Shouldn’t Give Big Brother a Head Start”.


Schneier is the inventor of the Blowfish and TwoFish block cypher algorithms as well as the Solitair cypher used in Neil Stephenson’s Cryptonomicon. TwoFish was a finalist to become the NSA’s advanced encryption standard (AES) but ultimately lost the competition to Rijndael.

%d bloggers like this: