“Security Suite” Subscriptions are the Dumbest Idea in Computer Security

I recently came across a 2005 essay by Marcus Ranum entitled “The Six Dumbest Ideas in Computer Security”. #1 on Ranum’s list is “Default Permit”.

Another place where "Default Permit" crops up is in how we typically approach code execution on our systems. The default is to permit anything on your machine to execute if you click on it, unless its execution is denied by something like an antivirus program or a spyware blocker. If you think about that for a few seconds, you’ll realize what a dumb idea that is. On my computer here I run about 15 different applications on a regular basis. There are probably another 20 or 30 installed that I use every couple of months or so. I still don’t understand why operating systems are so dumb that they let any old virus or piece of spyware execute without even asking me. That’s "Default Permit."

#2 on Ranum’s list is a special case of #1 which he calls “Enumerating Badness”. Basically what that boils down to is keeping a running list of “bad” stuff and preventing that from happening.

"Enumerating Badness" is the idea behind a huge number of security products and systems, from anti-virus to intrusion detection, intrusion prevention, application security, and "deep packet inspection" firewalls. What these programs and devices do is outsource your process of knowing what’s good. Instead of you taking the time to list the 30 or so legitimate things you need to do, it’s easier to pay $29.95/year to someone else who will try to maintain an exhaustive list of all the evil in the world. Except, unfortunately, your badness expert will get $29.95/year for the antivirus list, another $29.95/year for the spyware list, and you’ll buy a $19.95 "personal firewall" that has application control for network applications. By the time you’re done paying other people to enumerate all the malware your system could come in contact with, you’ll more than double the cost of your "inexpensive" desktop operating system.

The prices have gone up a bit with inflation:

  • Norton Internet Security Suite $70/year
  • Kaspersky PURE Total Security $90/year
  • McAfee Total Protection $90/year

Basically what you get for your $60-90/year is a system that double-checks everything that you try to do isn’t something bad that it knows about and if it is tries to stop it and if it lets something nasty happen tries to fix it later. You have no guarantee that something bad won’t happen because your computer still defaults to executing all code and, as a bonus, your expensive new computer now runs like molasses.

Default Deny is an Available Option in Windows 7 (but not by default)

Windows 7 ships with a semi-obscure enterprise feature called AppLocker. What AppLocker can do is deny execution to all programs, scripts, installers and DLLs by default. Instead of the normal situation where everything runs, only the code that matches ApplLockers known-good rules is allowed to execute. It works in conjunction with non-administrator user accounts to ensure that the only code executing on your system is code you want executing. This sleeper that nobody has ever heard of is more effective at stopping malware than any security suite on the market can ever be.

Why does this work? Your every day account has limited rights so it can’t write files into protected parts of the operating system but only software installed into protected parts of the operating system are allowed to execute. That means its impossible to execute downloads, email attachments, files on USB drives or whatever. Even if your browser or a plugin like Flash is exploited by malicious code in a web page, it is severely limited in the damage it can do. The usual end game of browser exploit code is to download malware onto your computer, install it somewhere and execute it. With an AppLocker default deny policy the end game can’t happen. This makes an anti-malware system something of an afterthought. Antimalware software becomes nothing more than good hygiene rather than the beachhead of your computer security, so make sure to use something that is free, lightweight and unobtrusive.

The catch is that AppLocker is an “Enterprise” feature that is only available in Windows 7 Enterprise or Ultimate editions. Also, there is configured through the Group Policy enterprise management tool which is targeted at professional systems administrators rather than normal people.

It turns out to also be cheaper to upgrade to Windows 7 Ultimate than to pay for 3 years of anti-malware. Let’s assume that your computer has a 3-year life.

Windows Anytime Upgrade Price List

  • Windows 7 Starter to Windows 7 Ultimate: $164.99 or $55/year amortized over 3 years
  • Windows 7 Home Premium to Windows 7 Ultimate: $139.99 or $47/year amortized over 3 years
  • Windows 7 Professional to Windows 7 Ultimate: $129.99 or $43/year amortized over 3 years

Even if it weren’t cheaper than massive security suites, enabling a default deny execution policy is so fundamentally right it is crazy not to do it. Any corporate IT department deploying Windows 7 without enabling AppLocker is either incompetent or the organization places no value on information security. For home users, the configuration is doable but it is “enterprisey” which means the configuration interface is too daunting for most people.

If Microsoft cares about protecting its users, it should enhance AppLocker so that it has a consumer-friendly configuration interface and it should turn on AppLocker by default in all SKUs, just like the Windows Firewall is on by default.

The day can’t come soon enough that Windows ships with a default deny firewall and a default deny execution policy and limited rights users by default. Maybe it will all come together in Windows 8.

Really Least-Privilege Development: AppLocker and Visual Studio

AppLocker is a software execution policy tool in Windows 7 Enterprise and Ultimate and Windows Server 2008 R2. An AppLocker policy can be used to shift Windows from a  model where execution of code is permitted by default to a model where execution is denied by default. AppLocker is aware of binary exe, DLL/OCX, the scripting engines that ship with Windows and Windows Installer packages. The default rule sets for these categories will only allow code that is installed into the system or program files directories to execute. Once AppLocker is turned on, execution of code is denied by default and an unprivileged user cannot add executable code to the system.

If untrusted users can’t execute new code, then how can Visual Studio possibly work without making developers admin?

Grant Execute on Source/Build Tree: Fail

I thought this would be super simple and that all I would have to do was create Executable, DLL and Script path rules to grant execute on my source tree. At first, it seemed to work and I was off and running. Then I tried to build a big complicated project and the build failed all of a sudden. This solution had post-build rules but so what? I had script enabled for the build tree.

Build Actions Fail

Procmon shows that the pre- and post-build events are implemented as temporary batch scripts in %TEMP%. They are named <cryptic-number>.exec.cmd.

procmon-postbuild

Unfortunately %TEMP% is not a usable macro in AppLocker. You have to either create a generic Script rule to allow all *.exec.cmd scripts to execute or create rules for each Visual Studio user like C:\Users\<username>\AppData\Local\Temp\*.exec.cmd. Either way, post-build actions will start to work.

Web Apps Crash with Yellow Screen of Death

Another issue is that running Web apps with the built-in Visual Studio Development Web Server (aka Cassini) fails miserably. The obvious clue that this is AppLocker is “The program was blocked by group policy.”

webdev.webserver20-yellowdeath

The problem is that Cassini copies the DLLs and runs them from a subdirectory of %TEMP%\Temporary ASP.NET Files\.

webdev.webserver20-temp

 

In order for Cassini to work, you have to disable DLL rules or  create a DLL allow path rule for every developer in the form C:\Users\<username>\AppData\Local\Temp\Temporary ASP.NET Files\*.dll.

Visual Studio’s HelpLibAgent.exe Crashes

This one is a bit weirder and more surprising. Visual Studio 2010 has a new help system that operates as a local HTTP server. Invoking help with AppLocker DLL rules enabled generates a serious crash.

helplibagent-crash

I’m not sure why it does this but HelpLibAgent.exe generates a random string and then two .cs files based on that string and invokes the C# compiler to generate a DLL based on the random string which is dynamically loaded by HelpLibAgent. This seems weird on the face of it that and there’s nothing in that code that looks like it has to be generated on a per-user basis at all. Weird, weird, weird.

helplibagent-dll-compile

In order for this to work you have to allow any randomly named dll to load out of %TEMP% which means disabling DLL rules or modifying the rule that was necessary for Cassini:

C:\Users\<username>\AppData\Local\Temp\*.dll.

Summary

In order to run Visual Studio with AppLocker a user needs the following rules:

  • DLL, EXE and Script: Allow path on source tree / build directory structure
  • Script: Allow path on %TEMP%\*.cmd.exec
  • DLL: Allow path on %TEMP%\*.dll
  • Unfortunately %TEMP% is not available in AppLocker so a C:\Users\<username>\AppData\Local\Temp\* for every <username> needed has to exist. These are probably best implemented as local policies.
  • Optional: Allow script *.ps1. (This is pretty safe because PowerShell has its own tight script execution security model.)
  • It’s unfortunate that DLL rules have to be enabled for a well-known location like %TEMP% but that still doesn’t make the DLL rule useless.

    • OCX is still not permitted from %TEMP%
    • AppLocker DLL rules are complementary to CWDIllegalInDllSearch for mitigating DLL Hijacking because it provides a more granular options. This is particularly important if you need to use a global CWDIllegalInDllSearch setting of 1 or 2 for compatibility reasons.
    Once these rules are in place, the experience is seamless. The rules don’t get in the way of anything.
    Note that AppLocker script rules only apply to the scripting hosts that ship with Windows: CMD, Windows Scripting Host (.vbs and .js) and PowerShell). Perl, Python, Ruby, etc interpreters are not affected by AppLocker policy. Similarly, execution of Java jar files are not affected by AppLocker.
    It would be nice if DLL rules were a little smarter. For instance, I would like to be able to allow managed DLLs on some path but not native code.

Headbang: Chrome, Flash and AppLocker Don’t Play Together

Google Chrome has bundled  a private copy of Flash since 5.0.375.86. Flash is packaged as gcswf32.dll in the Chrome application folder. All of the EXE and DLL files that come with Chrome as cryptographically signed by Google except for gcswf32.dll which is not signed at all. However, the NSAPI compatible Flash plugin distributed by Adobe is signed by Adobe.

This matters if you are using AppLocker DLL rules to define execution rules because there is no good way to create a permit rule for this DLL. AppLocker is a component of Windows 7 Enterprise and Ultimate SKUs which provides a straightforward mechanism for configuring Windows with a usable default-deny execution policy.

If you enable AppLocker EXE and DLL rules with the default rule set, Chrome will not run at all because Chrome is installed into the %userprofile%\AppData\AppData\Google\Chrome directory structure which is writable by unprivileged users. The obvious solution is to create EXE and DLL rules to permit code published by Google to execute. This works great, except that Flash will not execute. Why oh why is gcswf32.dll not signed by either Google or Adobe? There’s no way to whitelist this DLL except creating a permit *\gcswf32.dll rule or giving up on DLL rules altogether.

Workaround

A viable workaround is to use about:plugins to disable the Flash plugin Google distributes and globally install the “Flash player for Firefox, Mozilla, Netscape, Opera (and other plugin-based browsers)”. This plugin gets installed into C:\Windows\SysWOW64\Macromed\Flash on x64 or C:\Windows\system32\Macromed\Flash on x86 (and is signed by Adobe) is whitelisted by the default DLL rule set because it is inside of the Windows directory.

applocker-exeapplocker-dlldisable-chrome-bundled-flash

Chrome Team, Please Fix Me

You have to disable the bundled Flash player bundled by Chrome in order for Flash to work under this scenario, which means this is a workaround that is not enterprise ready unless your company is full of nerds. Also, this means that I have to worry about updating Flash instead of Chrome just handling it.

AppLocker is good stuff. Chrome is good stuff. I’d these technologies to play better together.

All Google needs to do is distribute a signed version of the Flash player plugin. Why aren’t they already doing this, anyway?

Please Chrome team, this is trivial to fix. Thanks in advance.

Reported as issue 65322.

Edit

A reasonable solution is to use the Chrome enterprise MSI installer which installs Chrome into the standard “program files'” location which means the default AppLocker permit rule on “program files” covers Chrome.

Update

I’m not sure when Google started distributing signed versions of Flash but in Chrome 12, gcswf32.dll comes with a valid signature from Adobe.

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

C:\users\breiter\AppData\Local\Google\Chrome\Application\chrome.exe.

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

publisher

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.

Developers

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\*”.

Limitations

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

EDIT

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.

%d bloggers like this: