Microsoft's USGCB Tech Blog

Legacy Web App Security and Sysinternals at TechEd North America + Europe 2012

Aaron Margosis — Wed, 06 Jun 2012 23:37:20 GMT

I'm presenting a couple of sessions at TechEd North America 2012 in Orlando (June 11-14) and at TechEd Europe 2012 in Amsterdam (June 26-29).

The first session is "Sysinternals Primer: Gems", the latest in the Sysinternals Primer series (*).

In the latest edition of the popular Sysinternals Primer series, join Aaron (Mark Russinovich's co-author of The Windows Sysinternals Administrator's Reference) as he goes mining for gems. Uncover buried tips and tricks to get the most out of popular tools such as Process Explorer and Process Monitor. Discover treasures among the least-known Sysinternals utilities -- tools that you would have been using if you had only known about them sooner. The Sysinternals utilities are vital tools for any computer professional on the Windows platform. Mark Russinovich's popular "Case Of The Unexplained" demonstrates some of their capabilities in advanced troubleshooting scenarios. This complementary tutorial series focuses primarily on the utilities themselves, deep-diving into as many features as time will allow.

By the way, Mark Russinovich and I will be at the TechEd US bookstore from 11:30-noon on Wednesday and Thursday to sign copies of our book, Windows Sysinternals Administrator's Reference. Mark will also be signing copies of the brand new Windows Internals, 6th Edition, Part 1 and his novel Zero Day. We'll also have a book signing at TechEd Europe -- date/time to be announced.

The second session I'm delivering is "Defense Against the Dark Ages: Your Old Web Apps Are Trying to Kill You":

The web browser is the primary path that malware uses to get on users' computers. Web browser security (especially Windows Internet Explorer) has improved dramatically in the past few years to defend against evolving threats. However, continuing to build and maintain web apps using old practices defeats many of these improvements and leaves your users' computers more vulnerable than ever. In this session, learn why those formerly accepted (or at least tolerated) practices are surprisingly harmful and now must be updated. Learn ways to update web apps quickly so that you can adopt more secure practices without stopping your business.

For those who have been waiting for the "what do I do now" Part II to my blog post, Enabling “Initialize and script ActiveX controls not marked as safe” in ANY zone can get you hurt, bad, I will talk about and demonstrate an economical but safe solution. It may be the only time in a decade that anyone at a Microsoft conference has demonstrated how Visual Basic 6 might be your best option. (!!!)

(*) Previous Sysinternals Primer sessions are available online:

Correction posted for IE Explicit Security Zone Mappings and IEZoneAnalyzer's Zone Map Viewer

Aaron Margosis — Tue, 15 May 2012 05:37:10 GMT

I received some questions and comments about Internet Explorer's Explicit Security Zone Mappings and about the latest version of IEZoneAnalyzer containing the Zone Map Viewer. I hadn't had time to dig into the questions so they lingered, but I finally carved some time to post answers to those questions in the Comments sections of those two posts. I also found one bug both in my write-up about the mappings and in IEZoneAnalyzer, where I had the precedence order wrong when a particular site is defined both in Computer Configuration's and in User Configuration's Site to Zone Assignment List. I have corrected the content of the original write-up (also downloadable as a Word doc) and posted an updated version of IEZoneAnalyzer (v3.5.0.4).

Enabling “Initialize and script ActiveX controls not marked as safe” in ANY zone can get you hurt, bad.

Aaron Margosis — Thu, 03 Nov 2011 18:14:00 GMT

This post is about a security setting that is often underestimated in its ability to enable serious harm when relaxed. But relaxing it is exactly what I often see being done in enterprise environments. The risk is real that anyone who has any control over any content on any web server in those security zones could easily and surreptitiously take complete control of visitors’ computers and user accounts, and in a way that could be difficult or impossible to trace. You should make sure the setting is disabled. Full details (and demo) in the blog post.

...(read more)

Top Ten Deployment Blockers

Aaron Margosis — Tue, 18 Oct 2011 19:44:35 GMT

My colleague Shelly Bird, a highly esteemed Architect in Microsoft Public Sector Services, has years of experience in desktop and server deployments. She has seen what works and a whole lot of what doesn’t. Now she is bringing her observations to the blogosphere, kicking off with a Top Ten list of deployment blockers. I was really excited when she told me about it because it’s not going to be just another tech-oriented blog about scripting how-to, specific security settings and application compatibility. While those issues are important to deployment projects, that’s not where projects tend to run into the most trouble. This is much higher-level and should be read by executives. It’s not really even Windows-specific. It’s about decision-making (or decision-delaying) and organization culture issues.

Forward this link to your management and executives. If you are a manager or an executive, forward it to your colleagues and friends:

The Deploy Depot Blog

Alert: Java’s Forward-Compatibility Promise Has Been Revised

Aaron Margosis — Tue, 18 Oct 2011 15:59:00 GMT

Java’s Forward-Compatibility Promise

Writing forward-compatible software is really hard. You carefully write your programs strictly according to the current specifications for your target platform, and it works perfectly well on that platform. But eventually that platform and its specifications will be updated. It will effectively become a different platform, and you really have no way to know whether the implicit assumptions you had made will still hold. Some internal implementation detail may have changed that breaks your program, or the rules for the new platform disallow behaviors you had depended upon, such as storing data in a particular location, or expecting that since “foo” was not a language keyword it wouldn’t become one in the next version.

The makers of the Java programming language and Java Runtime Environment (JRE) thought they had it figured out. Their answer was that different versions of Java could be installed and run side by side, and if your app was known to work with a specific JRE (say, version 1.2.2 Update 14), you could always just specify that version and use it. If a newer version of the JRE were installed, everything would be fine as long as the version you needed were also still installed. Your app would simply continue to use the older version. Write once, test once, run forever. Forward compatibility guaranteed! Brilliant!

Naturally, many responsible and conscientious developers continue to leverage this feature to ensure that their code continues to perform as originally tested. “It was developed, tested and known to work on 1.2.2_14 and so we require that version.” In particular, I see many custom, internal line of business (LOB) apps at my customers that require a specific, old JRE version.

The Promise Revised

Well, it seemed like a good idea at the time.

Back then, “older version” was not automatically considered to be synonymous with “riddled with easily exploitable security bugs.” However, many JRE updates are Critical Patch Updates (CPUs) that fix such bugs. You cannot keep the older version and be protected against exploits. Why? Because any web app can specify any vulnerable JRE you happen to have installed and run attack code on your computer. Further, the older JRE families (JRE 1.5/5.0 family and earlier, as well as JInitiator) are no longer supported and so while malware authors can continue to develop attacks for those older versions, the vulnerabilities are not being fixed and just remain exploitable. Further, Oracle points out that older, unsupported versions may also be vulnerable to newly-discovered flaws found in newer, supported versions:

“Unsupported products, releases and versions are not tested for the presence of vulnerabilities addressed by this Critical Patch Update. However, it is likely that earlier versions of affected releases are also affected by these vulnerabilities. Hence Oracle recommends that customers upgrade their Oracle products to a supported version.”

“Critical Patch Update patches are not provided for product versions that are no longer supported. We recommend that customers upgrade to the latest supported version of Oracle products in order to obtain patches.”

Meanwhile, vulnerable versions of Java have become the most widely attacked software component on Windows computers. It was about a year ago that the Microsoft Malware Protection Center first reported observing a sudden, large spike in attacks on Java, following a more modest but significant rise reported earlier by Symantec. The latest Microsoft Security Intelligence Report (v11) confirms that Java remains the top target of malware, with Java exploits “responsible for between one-third and one-half of all exploits observed in each of the four most recent quarters.”

Should you continue to use older versions of Java, or even have them installed on your systems? Probably not – the risk is obviously high. Oracle (which acquired Sun Microsystems and Java) specifically recommends that you do not. Says Oracle:

We highly recommend users remove all older versions of Java from your system.

Keeping old and unsupported versions of Java on your system presents a serious security risk.

A customer recently asked me what the risks would be to standardize on 1.6 Update 17. (As of this writing, the current public JRE is 1.6 Update 27.) Here are the JRE updates that have shipped since Update 17, going back to March 2010. They fix a total of 94 separate vulnerabilities, which are listed on the bottom of each of these pages:

March 2010, affecting Update 18 and earlier: http://www.oracle.com/technetwork/topics/security/javacpumar2010-083341.html
October 2010, affecting Update 21 and earlier: http://www.oracle.com/technetwork/topics/security/javacpuoct2010-176258.html
February 2011, affecting Update 23 and earlier: http://www.oracle.com/technetwork/topics/security/javacpufeb2011-304611.html
June 2011, affecting Update 25 and earlier: http://www.oracle.com/technetwork/topics/security/javacpujune2011-313339.html

In addition, only the latest versions of Java work on Windows 7, and versions of JRE 1.6 before Update 24 won’t work with IE9.

So What Do You Do Now?

So what can you do if you are using Java? First, you should follow Oracle’s recommendation and uninstall all but the latest supported version. Next, you should remove the requirement from your Java apps tying them to a specific version. Won’t all those apps break? That can be determined only through testing, but Oracle says that “the latest available version is always compatible with the older versions,” and goes on to say:

However, some Java applications (or applets) can indicate that they are dependent on a particular version, and may not run if you do not have that version installed. If an application or web page you access requires an older version of Java, you should report this to the provider/developer and request that they update the application to be compatible with all Java versions.

If that compatibility expectation is as reliable as Oracle says, then keeping your JRE patched should be as regular and uneventful as deploying Windows “Patch Tuesday” updates. Nobody performs comprehensive regression tests of all their applications before deploying Windows patches, because those patches almost never cause an app not to work.

Quite honestly, the alternative is too risky. Your Java developers should no longer insist that your house be protected with broken locks.

IEZoneAnalyzer v3.5 with Zone Map Viewer

Aaron Margosis — Fri, 23 Sep 2011 03:40:00 GMT

IEZoneAnalyzer is a utility for viewing and comparing Internet Explorer security zone settings – that is, the configuration settings that grant web sites in the Intranet zone more capabilities in the browser than web sites in the Internet zone. Earlier today, I wrote about the surprisingly complex rules that determine whether and when explicit mappings of websites to security zones take effect or are ignored. IEZoneAnalyzer version 3.5 adds a Zone Map Viewer that shows which web sites have been specifically assigned to security zones and whether the assignment is effective. Click on the “Zone Map Viewer” button in the main dialog’s toolbar to display the Zone Map Viewer. You can toggle the Zone Map Viewer between an “Effective Settings” view and a “Raw Settings” view with labeled toolbar buttons.

“Effective Settings” lists the configured web sites and the zones to which they are mapped. The Comments column calls out settings that are applicable only to 32-bit processes or only to 64-bit processes, or that are completely overridden and never take effect. For example, the first screenshot below shows a number of site assignments to Trusted Sites that are overridden because they are defined in User Preferences, but overridden both because the “use only machine settings” group policy is in effect and because a Computer Configuration Site-To-Zone Assignment policy is in effect. The screenshot also shows two overridden settings that are in effect only when Enhanced Security Configuration (ESC) is enabled, which is not the case as shown by the informational lines at the top of the listing. A given site is listed only once in the Effective Settings view. If a site is mapped the exact same way in a registry location that is in effect and in another that is not in use, the “overridden” one is not shown. That is, a setting is shown as “overridden” only if is defined somewhere differently from what is actually in effect.

The “Raw Settings” view, shown below, shows all site-to-zone configuration settings, listing where they are defined, the zone each is assigned to, and whether that particular setting is in effect or ignored. Both views show the criteria that are used to determine which ZoneMap settings are in effect and which are ignored (per the rules listed in the Appendix.)

As with all other IEZoneAnalyzer views, columns can be sorted, resized and reordered; content can be searched for specific text, copied to the clipboard and exported to CSV and to Excel files. Further, the sort order for the “Website” columns is based on domain names rather than on a strict alphabetic order. For example, all the “microsoft.com” mappings are grouped together, alphabetized by subdomains in reverse order.

[Updated 14-Oct-2011: Posted v3.5.0.3 to fix a bug, and to change the text associated with URL Action 180C which ended up not being used by Windows or IE.]

[Updated 15-May-2012: Posted v3.5.0.4 to fix a bug involving precedence of Computer policies over User policies.]

[Updated 7-June-2012: Re-posted v3.5.0.4 with the documentation back in! Sorry about that.]

Internet Explorer’s Explicit Security Zone Mappings

Aaron Margosis — Thu, 22 Sep 2011 16:04:00 GMT

[Updated 15 May 2012 to correct a bug involving precedence of Computer policies over User policies.]

I recently worked with some customers who wanted to enumerate which web sites had been assigned to which Internet Explorer security zones. I.e., they wanted to know which web sites had been assigned to the Intranet zone, which to Trusted Sites, etc. In the course of this work I uncovered some surprising complexities about site-to-zone assignment rules that had not yet been documented. This blog post describes those discoveries. Later today I will post an updated version of IEZoneAnalyzer that lists the sites that have been configured and whether those settings are in effect or ignored. [Update: it's been posted.]

[I'm not happy with the way the blog software has reformatted this document; rather than spend the day fighting it I'm attaching the original Word doc to this post.]

Overview

Internet Explorer applies a set of rules to associate web sites (URLs) with security zones, based on criteria such as whether the server has a dot in its name. In addition, group policies, computer settings and user preferences can be used to map specific URLs to specific zones. For example, you could explicitly add “https://www.contoso.com” to the Trusted Sites zone. Such site-to-zone mappings are defined under one or more ZoneMap key hierarchies in the registry. There are five different locations where ZoneMap key hierarchies can be defined, but only one or two of them will be in effect at any particular point in time. Exactly which settings under which ZoneMap keys are effective depends on a number of circumstances:

· Whether Site-To-Zone-Assignment lists are configured in Computer Configuration and/or User Configuration group policies;

· Whether the “Security Zones: Use only machine settings” group policy is configured (a.k.a., Security_HKLM_only);

· Whether Internet Explorer’s Enhanced Security Configuration (ESC) is enabled (Server only);

and, quite surprisingly:

· Whether or not the program is a 32-bit process on 64-bit Windows; a.k.a., “Windows On Windows 64” or WOW64.

Yes, that’s right – in some circumstances, a 32-bit process and a 64-bit process on the same computer can see the same site mapped to different security zones.

Also, my testing indicates that there is a bug that results in all URLs being treated as “Internet” zone when both ESC and a Computer or User Site-To-Zone-Assignment list are enabled.

Explicit Site To Zone Rules

The rules for selecting ZoneMap keys are listed below. Each table shows some combination of the four circumstances described in the overview; following each table is the key or keys that are in effect in those circumstances. There are separate settings under each ZoneMap key for “ESC on” and “ESC off”. If ESC is on, only those settings under the EscDomains and EscRanges subkeys are used; if ESC is off, only the settings under the Domains and Ranges subkeys are used.

Note that in the tables below, WOW64 set to “Yes” means a 32-bit process on a 64-bit version of Windows. WOW64 set to “No” means either a 32-bit process on a 32-bit version of Windows or a 64-bit process on a 64-bit version of Windows.

WOW64	Security_HKLM_only	Computer Site-To-Zone	User Site-To-Zone
Yes	Cleared	Absent	Absent

Combines results from

HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap

HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap

User preferences (in HKCU) take precedence over computer preferences

WOW64	Security_HKLM_only	Computer Site-To-Zone	User Site-To-Zone
No	Cleared	Absent	Absent

Combines results from

HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap

User preferences (in HKCU) take precedence over computer preferences

WOW64	Security_HKLM_only	Computer Site-To-Zone	User Site-To-Zone
Yes	Set	Absent	Either

HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap

User site-to-zone assignments are ignored if present

WOW64	Security_HKLM_only	Computer Site-To-Zone	User Site-To-Zone
No	Set	Absent	Either

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap

User site-to-zone assignments are ignored if present

WOW64	Security_HKLM_only	Computer Site-To-Zone	User Site-To-Zone
Either	Either	Present	Absent

HKLM\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap

WOW64	Security_HKLM_only	Computer Site-To-Zone	User Site-To-Zone
Either	Cleared	Present	Present

Combines results from

HKLM\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap

HKCU\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap

Computer policies (in HKLM) take precedence over User policies

WOW64	Security_HKLM_only	Computer Site-To-Zone	User Site-To-Zone
Either	Set	Present	Either

HKLM\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap

User site-to-zone assignments are ignored if present

WOW64	Security_HKLM_only	Computer Site-To-Zone	User Site-To-Zone
Either	Cleared	Absent	Present

HKCU\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap

What About “ZoneMapKey”?

IT administrators trying to apply site-to-zone settings by directly manipulating registry values often discover two “ZoneMapKey” registry keys that appear to be more interesting than they actually are: specifically, HKCU\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMapKey and HKLM\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMapKey. Values under these keys look like the site-to-zone assignments applied through group policy, and in fact they are. However, these keys are not used directly by Internet Explorer, and if you directly set values there, they will have no effect. The ZoneMapKey entries are just a temporary writing place for the Group Policy engine, which writes entries there as specified by Group Policy, and then parses them into corresponding ZoneMap subkey settings that are used by Internet Explorer.

Set_FDCC_LGPO for Windows 7…

Aaron Margosis — Thu, 11 Aug 2011 01:52:00 GMT

… is not needed and will not be created. I had kind of blogged about this a while back but it was hidden under a more general title, so the question about Set_FDCC_LGPO on Windows 7 continues to get asked. This post offers another easy and flexible way for you to apply NIST’s GPOs and any customizations you need. All you need are ImportRegPol.exe and Apply_LGPO_Delta.exe and a simple PowerShell script. ImportRegPol and Apply_LGPO_Delta don’t require installation – you can run them directly – and PowerShell is already included in Windows 7.

Sidebar: For those of you who haven’t explored PowerShell yet, I have to say that it is the most revolutionary technology we have shipped in many years (well, other than Kinect for Xbox). PowerShell blows all other command line and scripting environments away. Beyond that, it has become my preferred programming environment, and I often use it to prototype ideas I later implement with C#. If you want to learn PowerShell really well, I highly recommend Bruce Payette’s book. Lee Holmes’ Cookbook is also a great resource. As long as I’m advertising books, I should mention Mark’s and my new Sysinternals book, although it has only a few mentions of PowerShell. OK, back to the topic…

Here’s all you need to do:

Extract the combined GPO zip file downloaded from NIST's site to your hard drive. To follow this example, extract it into C:\USGCB. (Note: don’t just download the zip file – extract its contents into C:\USGCB and retain the folder structures.)
Copy ImportRegPol.exe and Apply_LGPO_Delta.exe into C:\USGCB.
Using Notepad or any other text editor (I use vi.exe, believe it or not), create a PowerShell script called ApplyUSGCB.ps1 in C:\USGCB with the following commands, which you can copy and paste directly from here:

dir -recurse -include registry.pol |
  ?{ $_.FullName.Contains("\Machine\") } |
  %{ cmd /c start /wait .\importregpol.exe -m $_ /log .\Policies.log }

dir -recurse -include registry.pol |
  ?{ $_.FullName.Contains("\User\") } |
  %{ cmd /c start /wait .\importregpol.exe -u $_ /log .\Policies.log }

dir -recurse -include GptTmpl.inf |
  %{ cmd /c start /wait .\Apply_LGPO_Delta.exe $_ /log .\SecTempl.log }

.\Apply_LGPO_Delta.exe .\Deltas.txt /log .\Deltas.log /boot

Here’s how it works: The first command (which spans the first three lines) recursively searches for registry.pol files that have a full path including the text “\Machine\”; these are Computer Configuration administrative template files. Each one is is imported into Computer Configuration using ImportRegPol.exe with results logged to Policies.log. The “cmd /c start /wait” is needed because ImportRegPol and Apply_LGPO_Delta are not console applications, but we want the script to wait for the commands to complete before continuing the script. The second command does the same, but looking for User Configuration administrative templates under “\User\” folders. The third command searches for GptTmpl.inf security templates and applies them with Apply_LGPO_Delta, logging detailed results to SecTempl.log. The last command applies your policy customizations (see below), logging results to Deltas.log, and then rebooting.

Create a Deltas.txt file listing any modifications you want to make to the NIST-provided GPOs. I have attached the Deltas.txt that I often use for my own work to this blog post (you will probably need at least the WindowsFirewall changes it includes). The file must adhere to the Apply_LGPO_Delta file format (a simple text format described in the Apply_LGPO_Delta documentation). There are some other sample files you can use here.
You’re ready to go! Start PowerShell with administrative rights, and run the following commands:

Set-ExecutionPolicy RemoteSigned

cd C:\USGCB

.\ApplyUSGCB.ps1

The Set-ExecutionPolicy command needs to be configured only once. By default, PowerShell lets you run individual commands but not scripts. Setting the execution policy to RemoteSigned allows local unsigned scripts to run, but requires that any downloaded scripts or configuration files be digitally signed by a trusted publisher.

The “.\” before the script (and commands in the script file) are required because unlike the rest of Windows, PowerShell does not include the current directory in the search path.

IEZoneAnalyzer v3

Aaron Margosis — Thu, 14 Apr 2011 17:44:00 GMT

Announcing a major update to the IE security zone analyzer!

IEZoneAnalyzer is a utility for viewing and comparing Internet Explorer security zone settings. It is particularly valuable on systems controlled through Group Policy, on which the standard security settings dialog does not allow viewing of settings. IEZoneAnalyzer version 3 represents a total rewrite, adding a tremendous amount of new functionality compared to earlier versions. Note that IEZoneAnalyzer does not require administrative rights. It also does not have an installer – just run the utility directly. IEZoneAnalyzer does require.NET Framework 3.5.

Key features of IEZoneAnalyzer:

View effective security zone settings for any security zone on the local computer or exported from a remote computer and identify whether each setting was established by policy.
Compare settings between two or more security zones or templates.
View and compare entire sets of settings captured on different computers or on a single computer over time (e.g., to determine whether a system has drifted from its baseline settings).
Export results to Excel or to a Comma Separated Values (CSV) text file.
Filter comparison results to show only differences or conflicts.
Sort, reorder and resize result columns.
Copy selected or all results to the clipboard.

The download includes the program, sample files captured from various fresh systems with default settings, and extensive documentation. [Update, 22 Sept 2011: an updated version of IEZoneAnalyzer can be found here.]

Click on the thumbnails below to see full resolution screenshots:

View effective settings for the Internet zone captured on a Windows 7 x64 system with IE8 and USGCB settings applied:

Compare all IE security zone settings on a Windows Vista SP2 with IE7 to those from a Windows XP x64 with IE6:

Compare the Medium High template on the local computer, effective settings for the Internet zone on the local computer, and effective settings for the Internet zone captured on a Win7/IE8 system with USGCB settings:

Effective settings for the five security zones exported to Excel:

“AlwaysInstallElevated” is Equivalent to Granting Administrative Rights

Aaron Margosis — Tue, 25 Jan 2011 05:18:00 GMT

When removing administrative rights from end users, it’s important to ensure that there are no easy paths by which a user (or malware running as the user) can gain administrative rights. For example, don’t relax default permissions on system resources such as files, folders and registry keys, and don’t grant users any “admin-equivalent” privileges such as the Backup, Restore, Debug, or Load Driver privileges. On Windows XP, don’t put end users in the Power Users group. And always be on the lookout for and patch Elevation-of-Privilege (EoP) bugs in desktop management, anti-malware, firewall and other products. These EoP paths will be exploited by end users and by malware, defeating the purpose of removing admin rights and losing all the benefits of doing so.

I recently became aware of another setting that gives the end user admin-equivalent control over the computer. It’s a Group Policy setting for Windows Installer that, if enabled, runs any Windows Installer Package (.msi file) that the user launches under the all-powerful Local System account. The idea behind this setting is to allow users to install applications that they need, without directly granting the user administrative rights. However, it makes no distinction between a management-approved, digitally-signed installer of a business-critical application from a trusted publisher, and an unsigned MSI wrapper around a malicious script. That’s a real problem. Anybody can create an MSI – it doesn’t take deep knowledge, expensive developer tools or admin rights. In an environment with this setting, any user who wants admin rights can get them, and any malware that runs can silently take over the whole system.

This is a setting that appears to have managed somehow to fly under the radar of all of us security experts since its introduction in Windows 2000. Has it been exploited for evil purposes? That’s hard to know. Hopefully now that attention is drawn to it, we can close this hole before it is exploited by explicitly disabling the policy setting.

How easy is it? Well, if a picture is worth a thousand words, here’s an eight-thousand word essay.

Here’s a Windows 7 computer. I’m logged on as Toby, a Standard User. As you can see in the screenshot, the only members of the Administrators group are Abby and Administrator.

This computer has the AlwaysInstallElevated policy applied. It’s in both Computer Configuration and User Configuration, Windows Components \ Windows Installer, “Always install with elevated privileges”. It needs to be set in both Computer Configuration and User Configuration, and on this computer it is.

In a few minutes I built an MSI file called “AlwaysInstallElevatedTakeover.msi” containing the following script which will run as a custom action. (Yes, I like vi as a text editor. Too many brain cells committed to memorizing its commands to give it up.) This script prompts the user to enter a new user name and password, defaulting to “NewAdmin” and “Pass@word1”. It then creates a new local account with that user name and password and adds that new user to the Administrators group. It then opens a new Command Prompt with custom colors, lists the new membership of Administrators, and then awaits further instructions.

Here’s the MSI on my desktop, ready to go.

I run the installer, and after a moment it prompts me for a user account name. I use the default.

I also go with the default for the password.

And here’s the Command Prompt, running as Local System. It shows me that the membership of Administrators now includes the NewAdmin account!

And what the heck – as long as I have a Command Prompt with System privileges, I’ll add my Toby account to the Administrators group too, which will take effect the next time I log on. And I also have that NewAdmin/Pass@word1 account at my disposal.

Bottom line: in 2011, "AlwaysInstallElevated" is not how you want to do enterprise software deployment.

Adobe Reader X

Aaron Margosis — Mon, 29 Nov 2010 17:26:00 GMT

This post is a bit off-topic. Neither the Federal Desktop Core Configuration (FDCC) nor the US Government Configuration Baseline (USGCB) mandate specific settings for Adobe products, and it's a little unusual for a Microsoft blog to promote an Adobe product. However, this one is important.

Many of our customers make Adobe Reader part of their standard desktop image, or at least have it on the majority of their systems. Because of its ubiquity, Reader has become a major target for cybercriminals, with a scary increase in the number of exploited zero-day vulnerabilities over the last few years. When it’s Reader running on Windows that gets attacked (as it often is), our customers suffer.

Adobe has just released a major upgrade, Adobe Reader X, that should go a long way toward mitigating these attacks. Reader X incorporates a “Protected Mode” sandbox, not unlike the Protected Mode we implemented in Internet Explorer 7 and 8, in the Microsoft Office Isolated Conversion Environment (MOICE), and in Office 2010’s Protected View. Reader X’s Protected Mode should make it substantially harder to mount successful attacks against Windows computers via Adobe Reader. That’s good for our customers.

If you use Adobe Reader, you should begin evaluating Reader X right away.

This Adobe blog post announcing the release of Reader X includes links to additional information about its Protected Mode: http://blogs.adobe.com/asset/2010/11/adobe-reader-x-is-here.html

Web Application Test Plan

Aaron Margosis — Mon, 25 Oct 2010 09:00:00 GMT

This blog post describes how to perform basic web application testing to identify and fix compatibility issues. These procedures are designed for non-experts and not to require deep expertise in web application development. The target platform is assumed to be Internet Explorer 8 running on Windows 7 with standard user rights. Some of the issues covered below assume that the target platform has the US Government Configuration Baseline (USGCB) applied.

The test procedure is simply to log on to a Windows 7 computer, browse to a site to be tested, interact with the site and verify whether it behaves according to its specification. If the site appears to work correctly, good! Move on to the next one! If the site does not work as expected, review the list of issues below for matching symptoms.

Each issue listed includes a description, symptoms, workarounds during test/triage, and potential solutions, in the table format shown below. Review this example table first to understand the meaning of each of the table fields.

Issue Title

Description	A description of the underlying cause of the issue.
Symptoms	One or more symptoms that may appear if this issue is occurring.
Workarounds during test/triage	Temporary workarounds that can be used during testing. The purposes of these workarounds are: 1) to verify the root cause; 2) to temporarily get around the problem so that other features of the app can be tested. Note that it is only to be used during testing, not in production.
Potential solutions	Solutions that may be used in production.

A list of references follows the Issues section. The references explain Internet Explorer compatibility issues, such as the !DOCTYPE element that describes what version of web standards the site was designed for.

Issues

Missing ActiveX

Description	ActiveX required by web app isn’t present, and cannot be installed via a standard user’s browser.
Symptoms	Square with red X in upper left; Page content not fully shown, not active, nothing the user can do; ActiveX prompts.
Workarounds during test/triage	Log in as an administrator (or launch IE elevated) and install the ActiveX). This may require removing policies blocking ActiveX installation. Install the ActiveX through means other than with the browser (e.g., a standalone installer, or copy the control to the computer and run regsvr32 on it.)
Potential solutions	Pre-install into the image; Deploy with app deployment solution (e.g., SCCM); ActiveX Installer Service

Protected Mode

Description	Web app fails when run in IE Protected Mode
Symptoms	Failure of ActiveX or Java while in the Internet zone
Workarounds during test/triage	Ensure that the site is in Intranet (for internal apps) or Trusted Sites (for external apps). How to: if policy allows, use the IE security zone dialog (not allowed in USGCB configuration); otherwise, use Site To Zone Assignment List in Group Policy.
Potential solutions	Ensure that the site is in Intranet (for internal apps) or Trusted Sites (for external apps). Site To Zone Assignment List in Group Policy.

Rendering issues

Description	Layout of web page is incorrect; looked good in earlier versions
Symptoms	Layout is incorrect
Workarounds during test/triage	Click the Compatibility button to render in IE7 compatible mode. If that doesn’t work, press F12 to display Developer Tools and then Alt+Q to render in Quirks mode (if not already in Quirks). If that doesn’t work, look for conditional comments in the source (including in the CSS).
Potential solutions	Remove !DOCTYPE element and/or add X-UA-Compatible meta-tag or header to pages; update the content to be compliant with web standards as supported by the chosen rendering engine

Incorrect Version Checks in Script

Description	Application targets a specific version of Internet Explorer, and fails when it encounters a newer version number
Symptoms	“Unsupported version” error message; page interactivity missing; page missing styling
Workarounds during test/triage	Compatibility view (when site supports IE7); User Agent String utility; manually modifying the page to modify version vectors
Potential solutions	Compatibility view; modifying the web page source.

FIPS

Description	Requirement for FIPS crypto causes web app to fail. FIPS is one of the settings mandated by USGCB.
Symptoms	“Internet Explorer cannot display the webpage” on an HTTPS site. Verify with wfetch; failure shows “The client and server cannot communicate, because they do not possess a common algorithm”. (Example site: https://tmn.sun.com)
Workarounds during test/triage	Turn off FIPS setting, close all browsers, test again.
Potential solutions	Turn off FIPS setting, or get the site owner to upgrade to TLS.

SSL2

Description	Web server allows only SSL 2.0, which is disabled by default in IE8.
Symptoms	Failure to connect to an HTTPS site and FIPS not enabled. Verify connectivity by using wfetch and specifying SSL 2.0.
Workarounds during test/triage	Enable SSL 2.0 (Advanced page) and turn off FIPS crypto.
Potential solutions	Get the site to upgrade to a modern protocol.

Blocked Java

Description	Java Permissions setting prevents Java from running in the web page.
Symptoms	Gold bar, “An add-on for this website failed to run. Check the security settings in Internet Options for potential conflicts.”
Workarounds during test/triage	Ensure that the site is in the Intranet (for internal) or Trusted Sites (for external) zones, and ensure that the correct Java Permissions setting (“High safety”) is applied to that zone.
Potential solutions	Ensure that the site is in the Intranet (for internal) or Trusted Sites (for external) zones, and ensure that the correct Java Permissions setting (“High safety”) is applied to that zone.

Java Version incompatibilities

Description	Java app developers write the app to depend on a specific version of Java.
Symptoms	“Unsupported version” error messages; Incorrect behavior (which can vary based on the changes between Java versions); Assertions from the developers that a specific JRE is required
Workarounds during test/triage	Install “required” version of the JRE (note that there are versions of 1.4, 5.0 and 6.0 that are compatible with Windows 7, but only the 6.0 line is currently supported)
Potential solutions	Update the Java app not to depend on a specific Java version, and teach the Java devs to write forward-compatible software.

JInitiator

Description	Java app uses JInitiator, which is no longer supported and which doesn’t work well on Windows 7.
Symptoms	App requires JInitiator
Workarounds during test/triage	None
Potential solutions	According to Oracle, the latest Sun JRE obviates the need for JInitiator. Oracle recommends migrating JInitiator clients to Sun JRE.

Bugs in mobile code (e.g., ActiveX/Java assumes it has admin rights; using non-existent legacy paths)

Description	ActiveX or Java app is coded with hardcoded dependencies on legacy behavior, such as the web browser having full admin rights, or expecting certain folder names on the browser’s host system.
Symptoms	ActiveX or Java runs incorrectly
Workarounds during test/triage	Run browser with admin rights (note that for testing purposes the computer should be reimaged afterwards)
Potential solutions	Update the mobile code and/or the web application to remove the legacy dependency

IE Compatibility References:

IECTT, Event 1049 - Standards Mode:
http://msdn.microsoft.com/en-us/library/dd565650(v=VS.85).aspx

IE=EmulateIE7
http://blogs.msdn.com/b/ie/archive/2008/06/10/introducing-ie-emulateie7.aspx

KB 968499, “Advanced solutions: Some Web sites may not be displayed correctly or work correctly in Windows Internet Explorer 8” describes some Group Policy settings to control IE7 compatibility view
http://support.microsoft.com/kb/968499

IE’s Compatibility Features for Site Developers
http://blogs.msdn.com/b/ie/archive/2010/06/16/ie-s-compatibility-features-for-site-developers.aspx

How IE8 Determines Document Mode
http://blogs.msdn.com/b/ie/archive/2010/03/02/how-ie8-determines-document-mode.aspx

Testing Browser and Document Compatibility Modes with the Developer Tools
http://msdn.microsoft.com/en-us/library/dd565624(v=VS.85).aspx

Defining Document Compatibility
http://msdn.microsoft.com/en-us/library/cc288325(VS.85).aspx#DCModes

!DOCTYPE documentation
http://msdn.microsoft.com/en-us/library/ms535242(VS.85).aspx

Http-equiv documentation
http://msdn.microsoft.com/en-us/library/ms533876(v=VS.85).aspx

Conditional comments documentation
http://msdn.microsoft.com/en-us/library/ms537512(v=VS.85).aspx

Developer Tools User Interface Reference
http://msdn.microsoft.com/en-us/library/dd565626(VS.85).aspx

Quirks mode (Wikipedia)
http://en.wikipedia.org/wiki/Quirks_mode

Chris Jackson blogs frequently about application compatibility; these articles cover IE8 compatibility:
http://blogs.msdn.com/b/cjacks/archive/tags/internet+explorer+8/

Sticking with Well-Known and Proven Solutions

Aaron Margosis — Wed, 06 Oct 2010 17:02:00 GMT

I work with a lot of customers, and there are some problems I see over and over. One problem that I've seen and been thinking about a lot lately is the way that a number of customers paint themselves into a corner through excessive customization of their environment. Lately I've been making the case that they would be much better off by sticking with defaults or broadly known and well-tested configurations, and with proven enterprise solutions over home-grown tools.

First, let me make it clear that these situations generally haven't arisen from anyone's bad decisions. They were reasonable choices and possibly the best options available when the decisions were first made. However, desktop and application deployment, enterprise management and security guidance have evolved and matured rapidly over the past several years. We know a lot today that we didn't ten years ago. If your organization (like many others) is planning to migrate to Windows 7 soon, this is a perfect opportunity to revisit those decisions. I liken it to moving to a new house after living in the old one for ten years. You can pack all your old dusty, broken and ill-fitting possessions into boxes, ship them to the new house, then unpack the boxes and figure out where to fit all the clutter. Or you can take advantage of the opportunity to get rid of detritus and enjoy the new place.

What kinds of customizations am I talking about? They include but are certainly not limited to home-grown software for deploying applications and monitoring desktop configuration, enforcing non-standard file and folder locations or renaming those folders, enabling unnecessary and low-value security options, reverse-engineering and then depending on or even modifying undocumented registry data, and modifying the permissions of operating system files, folders and registry keys.

These customizations usually turn out to be expensive. They limit flexibility, increase the cost and complexity of managing the environment, and cause strange unexpected behaviors including patch failures. Have you had any of these issues in your environment?

Every piece of software to be deployed needs custom and time-consuming repackaging that is unique to your environment.
Your custom management solutions don't work on Windows 7.
The apps you purchase don't work the way they should without additional customization.
Ramp-up time for new personnel takes longer than it should because they need to learn all the idiosyncrasies of your configuration.
Bugs occur that wouldn't occur in a default or industry-standard configuration, and it takes a long time for techs to diagnose because they don't know about the quirks or realize their impact.
You have home-grown tools or scripts that have an admin password embedded in them. (This is always a bad security risk. Always.)
Your security experts don't think they're doing their job unless they put their own personal stamp on your security configuration, as if they get paid by the tweak.
If the guy who manages your app deployment gets hit by a truck, you'll probably go out of business.
The guy who owns the custom code insists that all commercial alternatives suck and won't work in your environment. (Perhaps you've had the sense that his ego and reality mutually agreed to separate a while ago.)

Sometimes you need to write your own software, particularly for line-of-business (LOB) purposes. But there is a vanishingly small need for any business to write or maintain its own desktop management or application deployment software. Unlike proven enterprise solutions, home-grown software tends to take dependencies on platform-specific features such as hardcoded file paths or undocumented system behaviors and to use undocumented and unsupported interfaces and registry data, which makes it hard to move to a new platform or even a standard configuration of your existing platform. They also tend not to meet the performance and scale characteristics or upgrade paths of proven products from a product group with robust testing and support organizations behind them.

Consider the US Government Configuration Baseline (USGCB). It includes a large set of security settings which is supposed to be mandated across the entire US Federal government. If you apply them, you're applying the same settings that lots of other groups have tested and worked with. Setting-specific issues will generally be well-known. Now consider the problem that one of my customers ran into just the other day. Along with a whole raft of other non-standard security settings, their security organization had applied the IE security option, "Do not save encrypted pages to disk," which prevents content that arrived over a secure HTTPS channel from being written to disk. On the face of it, doesn't that sound like a good idea? Sure! Enable that policy! After the new policies had been in production for a while, all of a sudden people panicked. It was payday, and the paystub web site was showing a blank page where it was supposed to display the user's paystub as a PDF document. Naturally, fixing this high-visibility issue was immediately assigned as the top priority to a group of tech experts who had to set aside other high priority tasks. Now, there are USGCB settings that are known to interfere with Adobe Acrobat Reader integration with Internet Explorer, and this is where I focused my attention. That turned out to be a dead end. A colleague of mine eventually took to disabling bunches of settings at a time to try to narrow down the issue, until he finally traced it to "Do not save encrypted pages to disk." Because this setting is not mandated or used by the FDCC, USGCB, or any Department of Defense configurations, the symptom and root cause was not one with which we were familiar, nor would it be one that I would expect most other people would think to focus on if they had not run into the problem themselves. Oh and guess what? It turns out that years ago this setting was specifically excluded from the earliest revisions of the US Air Force Standard Desktop Configuration (the ancestor of the FDCC) because of problems just like this.

Bottom line: if you stick with the Windows defaults wherever possible or industry-standard configurations such as the Microsoft Windows security guidance or the USGCB, and use proven enterprise management technologies instead of creating and maintaining your own, you will increase flexibility, reduce costs, and be better able to focus on your organization's real mission.

FDCC is now USGCB

Aaron Margosis — Sat, 02 Oct 2010 05:37:19 GMT

Along with the release of official government guidance for Windows 7, NIST has rebranded the Federal Desktop Core Configuration (FDCC) as the United States Government Configuration Baseline (USGCB). NIST's spreadsheets, Group Policy Objects (GPOs) and virtual hard disks (VHDs) for Windows 7 can be downloaded from http://usgcb.nist.gov. From this point forward, "FDCC" is just a four-letter word that starts with "F". :-)

At some point we may move our technical blog over to blogs.technet.com/b/usgcb, but for now we'll just change the title on the existing blog, to preserve existing bookmarks. Well, except that when the blog got rehosted a few months ago, ALL the URLs changed -- there is now a "/b/" between technet.com and fdcc. The same thing happened to all the other MSDN and TechNet blogs. Worse, all the "pages" that didn't have dates embedded in their URLs got relocated to date-specific blog posts. You can still find them by clicking on "Pages" under Tags. When I get a chance, I'll put them somewhere easier to find. (The minutes I had that I used to call "spare time" have become completely consumed with my taking over co-authorship of the Sysinternals Administrators Reference, working with Mark Russinovich. Hopefully I'll be winding that up before the end of the year.)

One of the frequently asked questions has been, "Where is the Set_FDCC_LGPO for Windows 7?" I've been thinking about creating that and changing some things about it, but in the meantime, it's still easy to automate the application of USGCB policies to local group policy, using the other two Local Group Policy utilities, ImportRegPol and Apply_LGPO_Delta (same link as for Set_FDCC_LGPO). Here's how:

Extract the GPO zip file downloaded from NIST's site to your hard drive.
CD into the top extracted folder (e.g., USGCB-1.0.x.0-GPOs), and copy ImportRegPol.exe and Apply_LGPO_Delta.exe into that folder.
Create a PowerShell script (ApplyUSGCB.ps1) with the following commands:

dir -recurse -include registry.pol | ?{ $_.FullName.Contains("\Machine\") } | %{ cmd /c start /wait .\importregpol.exe -m $_ /log usgcbpolicies.log }
dir -recurse -include registry.pol | ?{ $_.FullName.Contains("\User\") } | %{ cmd /c start /wait .\importregpol.exe -u $_ /log usgcbpolicies.log }
dir -recurse -include GptTmpl.inf | %{ cmd /c start /wait .\Apply_LGPO_Delta.exe $_ /log usgcbSecTempl.log }

These three lines find all the Computer Configuration and User Configuration Administrative Templates and all the security templates in the GPOs and incorporate them into the current computer's local group policies. You should reboot after these are completed; you can automate that by adding /boot to the Apply_LGPO_Delta command line.

One tip: some of the policies, particularly involving the Firewall settings, don't work so well when applied to local policy. If I remember correctly, two that get in the way are the DisableUnicastResponsesToMulticastBroadcast setting and the no-local-exceptions policies, and that when applied to local policy they prevent the computer from getting a DHCP address. What you can do is after extracting the GPOs, delete the Firewall Settings folder before running the PowerShell script, and find another way to apply firewall settings.

Sample Files for Apply_LGPO_Delta

Aaron Margosis — Wed, 24 Mar 2010 18:34:00 GMT

Apply_LGPO_Delta used to come with a bunch of sample files to address some common needs for policy adjustment, as well as a batch file to run Set_FDCC_LGPO and Apply_LGPO_Delta in sequence. Those samples inadvertently got omitted from an upload at one point. I've updated those sample files and added some new ones. They are attached to this blog post. The next time I update the utilities themselves I'll also put the samples in that zip file.

Job opening: Senior Software Development Engineer

Aaron Margosis — Wed, 27 Jan 2010 14:27:45 GMT

As you may know, the Federal Desktop Core Configuration is largely based on Microsoft’s Security Guidance for Windows. Well, the team in Redmond that creates and publishes that guidance has a job opening:

Do you have a passion for developing software and want to help our customers become more secure? Interested in making an impact on over 500,000 customers by regularly shipping software every 6-12 months?

Our team ships Solution Accelerators - we accelerate the adoption of the Microsoft platform by incubating exciting future product scenarios today. Our accelerators result in high customer satisfaction, huge downloads, and big changes in upcoming Microsoft products.

The Solution Accelerators for Security and Compliance is comprised of a small number of FTEs that plan, design, develop, and release our products, while managing a few key vendors to do additional development and test work. This high-scale model means that our FTEs focus on the most important aspects of the engineering lifecycle, work with engineering teams across Microsoft, and ensure top quality work from vendors.

If this interests you, check out the job description at https://careers.microsoft.com/JobDetails.aspx?ss=&pg=0&so=&rw=2&jid=10062&jlang=EN.

Updated LGPO utility sources

Aaron Margosis — Fri, 15 Jan 2010 17:15:00 GMT

The updated sources corresponding to the updated versions of the Apply_LGPO_Delta and ImportRegPol utilities are attached to this post.

Apply_LGPO_Delta and ImportRegPol updated

Aaron Margosis — Fri, 15 Jan 2010 17:14:00 GMT

I discovered an “unintended feature” in the Apply_LGPO_Delta and ImportRegPol utilities, which I have fixed in the versions now posted to the LGPO Utilities page. The “feature” (OK, the “bug”) allowed commands to set a registry value and to delete that registry value not to overwrite each other in the resulting registry policy file. This meant that if you had a policy that set a registry value, and then applied a delta file or imported a registry.pol with a command to delete that registry value, the resulting registry policy file would end up containing both the “set” and “delete” commands. Today’s update ensures that if a “set value” command is applied, any corresponding “delete” command for the same value will be removed, and vice versa.

The updated source is posted here.

Problems with FDCC’s XP File Permissions

Aaron Margosis — Thu, 03 Dec 2009 05:09:31 GMT

A few months ago I blogged about a case in which an ill-advised registry hack caused application failure. I also referred to KB 885409, which lists some of the problems that can arise when relatively untested third party security guidance around file and registry permissions settings are applied, like the Recycle Bins of administrator accounts becoming readable to all users on the system.

So it’s pretty embarrassing when our own security guidance fails in pretty much the same way.

Microsoft’s official Security Guidance for Windows XP includes a set of “optional file permissions” that block all access to various in-box utilities to everyone except Administrators and the SYSTEM account. The Federal Desktop Core Configuration requires some of these settings for Windows XP, blocking non-administrator access to the following utilities:

arp.exe
at.exe
attrib.exe
cacls.exe
debug.exe
edlin.exe
eventcreate.exe
eventtriggers.exe
mshta.exe
net.exe
net1.exe
netsh.exe
rcp.exe
reg.exe
regedit.exe
regedt32.exe
regini.exe
regsvr32.exe
rexec.exe
route.exe
rsh.exe
sc.exe
secedit.exe
subst.exe
systeminfo.exe
tftp.exe
tlntsvr.exe

Until recently, these lockdowns were included in Microsoft’s Windows XP Security Guide as a security template called “Optional-File-Permissions.inf”. That template has been removed from the latest version of the security guide, and the list of files has been slightly altered.

Specifically, we no longer recommend blocking access to Regsvr32.exe. Regsvr32.exe is a utility that is used to register COM and ActiveX DLL components, the vast majority of which can be registered only by administrators. However, it turns out that Regsvr32 is also invoked a couple of times when a user first logs on to a computer as part of the creation of that user’s profile. If a non-administrative user cannot execute Regsvr32.exe, then several parts of user profile setup do not happen. These include the creation and/or initialization of the user’s My Documents, My Pictures, My Music, Recent Documents, Send To, Favorites, and Quick Launch folders, MUI cache (for localized text), and many default visual settings. The Windows Shell team never tested under that configuration, and informs us that blocking access to Regsvr32 leads to a possibly unsupportable configuration.

Oops.

Note that none of these restrictions have ever been part of the security guidance for Windows Vista nor for Windows 7, and that the FDCC mandates file permissions changes only for Windows XP.

[Aaron’s Personal Opinion follows…]

I have never been a fan of any of these file restrictions, at least not on a general purpose computer that non-administrators routinely log into. Some of the utilities (such as at.exe and secedit.exe) require administrative rights anyway and so nothing is gained with further restrictions. Many others (such as net.exe, attrib.exe, reg.exe, and subst.exe) are frequently used in logon scripts and other batch files for routine and legitimate user profile maintenance and user session/environment setup. MSHTA enables the use of HTML applications. None of these utilities allow a non-administrative user to do anything that the user can’t do through scripts and/or graphical interfaces. They certainly do not allow the user to elevate privilege or to perform administrative operations. But creating a mapped drive using VBScript is a lot more complicated (and thus error prone) than using NET.EXE. In my opinion, these settings cause far more trouble than they’re worth.

Viewing and Comparing IE Security Zone Settings - enhanced

Aaron Margosis — Sat, 07 Nov 2009 08:26:00 GMT

I've enhanced the IE security zone comparison utility that I posted here a few weeks ago. The new version shows the effective settings for a selected zone, based on the precedence rules for User and Computer policies and preferences (as described here) and whether only Machine settings are used. Pick an IE security zone (such as Intranet), and the new IEZoneAnalyzer will show what settings are in effect and where those settings come from.

[Update 14 April 2011: just posted IEZoneAnalyzer v3 with lots of new features. See http://blogs.technet.com/b/fdcc/archive/2011/04/14/iezoneanalyzer-v3.aspx]

Viewing and Comparing IE Security Zone Settings

Aaron Margosis — Thu, 01 Oct 2009 22:27:00 GMT

The Security tab of the Internet Explorer Properties dialog shows security settings for the Internet, Intranet, Trusted Sites and Restricted Sites zones. However:

It doesn’t show settings for the Local Machine (Computer) zone, nor for Local Machine Zone Lockdown (LMZL).
When machine settings or other policies are in effect, most of the Security Zones UI is disabled.

The attached utility “IE Zone Comparer” was designed to overcome these limitations and provide additional visibility into security zone settings. Pick any two collections of security zone settings, and IE Zone Comparer displays the values of those settings, highlighting any differences between the two collections.

IE Zone Comparer requires .NET 2.0 or higher; it does not require administrative privileges.

How to use it:

Click “Pick Zones…” from the toolbar. The following dialog will appear:

The Effective Settings label indicates whether User settings are used or ignored. Refer to this blog post which discusses precedence order of the various policies and preferences.

For each column, there are two dropdowns. The first dropdown lets you select Templates, Machine Policy, Machine Preferences, User Policy, User Preferences, or FDCC Q1 2009 Policies. If you select Templates, the second dropdown lets you select one of the security zone templates (High, Medium-High, Medium, etc.); if you select Policies or Preferences, the second dropdown lets you select any of the five standard zones or five lockdown zones. (See this post for more information about all those zones.)

Click “OK” on the “Pick items…” dialog, and the selected settings will be rendered in the list view. Items that are present in both columns but with different values will be highlighted in yellow. Items that are present only in one column will be grayed in the other column.

Additional Features

To find a particular item with a partial text search, press Ctrl+F (or the “binoculars” toolbar dropdown). The text search is case-insensitive and searches in all columns from the currently-selected row down. Press F3 to repeat the last search from the current location.

Enter a URL in the text area in the toolbar and click “Map URL to Zone”: IE Zone Comparer will tell you in what security zone IE would render that URL.

The Help/About toolbar button includes some helpful links for more information about IE security zones and URL actions.

Some Example scenarios for the IE Zone Comparer

View effective settings for a particular zone. E.g., something isn’t working correctly on a page that is rendered in the Intranet zone. If user settings are being ignored, select Machine Policies / Intranet and Machine Preferences / Intranet. Policies override preferences; where no policy is set, the machine preferences will apply.
Compare the relative security settings of the Intranet zone vs. the Trusted Sites zone (see screenshot above).
Seeing exactly what changes when you transition from the Locked-Down Local Machine Zone to the regular Local Machine Zone. (Description here.)
Compare Machine Policies for a zone to the policies mandated by FDCC Q1 2009.
View the settings that are applied by a given template, and compare those settings to another template or to an existing zone to see whether it has been modified from that template.
Compare the effective settings of the Locked-Down Local Machine Zone (LMZL) to Local Machine Zone, to see what becomes enabled when the user clicks through the information bar.
Compare user preferences for a zone to the machine preferences for the same zone. (They should be the same; if they are not, then results may change when the “use only machine settings” policy is applied.)

[November 7, 2009: An updated version, IEZoneAnalyzer, has been posted that shows the effective settings for a selected zone and where each of the settings are established.]

The Case of the Unexplained Installation Failure (and an ill-advised registry hack)

Aaron Margosis — Mon, 28 Sep 2009 09:43:00 GMT

Since Mark Russinovich hasn’t trademarked his “Case of the Unexplained…” series, I’m appropriating the title to describe the results of some troubleshooting I did for a customer. The root cause turned out to be a widely-adopted but ill-advised registry hack that many organizations have built into their standard desktop images. If you’re not interested in the troubleshooting steps, skip ahead past the nerd content here and just read the Analysis. [Spoiler: it’s about the Autorun.inf “SYS:DoesNotExist” registry hack.]

The Case

The customer has Kodak scanners that come with CDs containing the required software. When the admin inserted the CD, Autorun didn’t quite work correctly – the Autorun dialog appeared but did not show the Autoplay option to install the software. So the admin opened the folder in Explorer and started autorun.exe to start the installation. Shortly after approving the User Account Control elevation request, the admin saw an error message with a strange title that looked like the installer was performing an incorrect OS version check:

App install error message

The Troubleshooting

I figured that the author of the installation program had assumed that since Windows XP was so perfect that Microsoft would never need to release another version of Windows, there was no reason to check for newer versions. I applied the WinXP compatibility mode (which among other things lies to the program about what the OS version actually is) and tried again. It failed in exactly the same way. What’s more, the installation worked perfectly well on freshly installed copies of Windows Vista that didn’t have the organization’s policies applied to it. Ah – so it’s not a Vista issue, there’s something in the policies!

I started Process Monitor, and ran the installation program again to the point of the error message and then stopped the Procmon trace. I dragged the Procmon crosshairs toolbar icon over the error message to apply a filter to show only events involving the window owner’s process (setup.exe).

Because of the “0” in the title in the error message, I thought the problem might be due to the program searching for something and not finding it, so I right-clicked on items in the Result column and excluded events with result codes I figured wouldn’t be interesting: SUCCESS, FAST IO DISALLOWED, FILE LOCKED WITH ONLY READERS, REPARSE, BUFFER OVERFLOW, and END OF FILE. (I usually exclude results that I want to filter out rather than include results that might be interesting because it’s easy to miss some when setting “include” rules.)

When I looked at the remaining entries, one thing that quickly stood out was the name “DoesNotExist” appearing in path names near the end of the results. I used Procmon’s highlighting feature to make them stand out in the context of surrounding events.

Because the surrounding context didn’t give me an idea of what had happened immediately prior to these failed searches, I took advantage of Procmon’s non-destructive filtering and removed the filter rule that excluded SUCCESS results. As you can see in the screenshot, there had been a bunch of file accesses to D:\setup.ini and then a few to D:\autorun.inf before the attempted registry access to HKLM\Software\DoesNotExist\Info.

I opened the event properties for the first RegOpenKey event and looked at the call stack to get an idea of how and why setup.exe was trying to open that key. Line 12 of the stack showed that the randomly-named component of the setup program was calling into GetPrivateProfileStringA, which led (in line 7) to an attempt to open a registry key.

GetPrivateProfileString is one of the APIs that Windows programmers can use to read from files that are formatted like the old .ini files from 16-bit Windows. And as its documentation points out, those accesses can be redirected to the registry with an IniFileMapping. I located the IniFileMapping that redirected autorun.inf to “DoesNotExist”, deleted it, rebooted, and the installation then worked correctly.

IniFileMapping entry redirecting Autorun.inf to a non-existent registry key

The Analysis

What is IniFileMapping?

IniFileMapping has been part of Windows since NT 3.1. When programs use the ini-file APIs to access files, an IniFileMapping entry can redirect the access to the machine or user registry (HKLM or HKCU). IniFileMapping was designed to help older apps that used .ini files to use the registry instead, to take advantage of the scalability benefits and to enable multiple users to have their own copies of settings instead of sharing a single ini file.

What is Autorun.inf?

When a removable disk, such as a CD or a USB drive, is inserted and Windows detects the new disk, Windows Explorer checks for an Autorun.inf file in the root folder of the drive. The Autorun.inf is a text file formatted as an .ini file (that is, section names in square brackets, name=value pairs within each section). It can include entries which tell Explorer what icon to display for the drive and a default Autoplay action to offer to the user, or in some cases, the program can just begin running. This is the mechanism that allows a program installation to automatically start just by inserting a CD. There are registry settings and group policies that can control whether and how Autorun and Autoplay work. (That link also describes the distinction between Autorun and Autoplay.)

A problem with Autoplay is that by default it has also been applied to writable drives such as thumbdrives. Worms like Conficker were able to propagate through such devices by writing an Autorun.inf and a copy of itself to the drive. The malware could then infect other computers simply by inserting the drive. That was compounded by a bug in the implementation of the settings that were supposed to disable Autoplay. That bug has since been fixed. Furthermore, updated Windows systems now have Autoplay disabled by default for writable drives. Autorun and Autoplay still work for CDs and DVDs, as the threat of worm propagation through that avenue is much smaller and (at this time) does not outweigh the benefits.

Why does this computer have an IniFileMapping for Autorun.inf?

A couple of years ago, a blog post described a clever trick to disable Autoplay for all drives. The trick leveraged the fact that Autorun.inf is formatted as an ini file and that Explorer uses the ini file APIs to read it. By creating an IniFileMapping for Autorun.inf that redirects access to a non-existent registry key, Autoplay entries cannot be read. The author asserted that the only negative effect is that users must browse for the file to execute. As more malware began using writable removable drives as a propagation mechanism, CERT and other security-conscious organizations began recommending this trick, adding the assertion that “This setting appears to disable Autorun behaviors without causing other negative side effects.” Since then, the setting has been mandated as part of the standard image for many organizations.

Why did this application install fail?

It turns out that the Autorun.inf on Kodak’s installation CD contained much more than just Autoplay entries:

[autorun]
open=autorun.exe

[Info]
Dialog=Kodak i610/i620/i640/i660 Scanner
Model=600
ModelDir=kds_i600
ProgramGroup=i610,i620,i640,i660

[Versions]
CD=04040000
FIRMWARE=04000300
ISISDRIVER=2.0.10711.12001
ISISTOOLKIT=57.0.260.2124
KDSMM=01090000
PKG=02010000
SVT=06100000
TWAIN=09250500

[Install]

[SUPPORTEDOSES]
WIN=WINVISTA WINXP WIN2K

[REQUIREDSPS]
WINXP=1
WIN2K=3

Kodak uses the Autorun.inf not only for Autoplay but as a general-purpose ini file containing configuration settings for the installation program. The installation program of course uses standard APIs to read the file, but the IniFileMapping redirects to a non-existent registry location, causing the installer to fail. It needs to be said here that what Kodak is doing is perfectly legitimate. There are no guidelines that say that the Autorun.inf cannot contain other application specific settings.

Could the customer have worked around the problem by copying the CD content to the hard drive and running it from there? No. The IniFileMapping setting applies to any file called Autorun.inf no matter where it is.

The bottom line is that the installation failed because the assurances of no “negative side effects” were not backed with extensive compatibility testing, and denies legitimate usage scenarios.

Recommendation

Customers who want to block Autoplay should use supported mechanisms rather than relatively untested hacks that can end up causing unintended side effects. I’ve seen plenty of cases where a non-standard setting that seems to many to be perfectly safe turns out to have serious repercussions that aren’t discovered for years. (That sort of thing led to the publishing of KB article 885409.)

Source code for New and Updated Local Group Policy utilities

Aaron Margosis — Tue, 15 Sep 2009 17:35:00 GMT

Visual Studio 2008 source and project files for the new ImportRegPol utility and the updated Set_FDCC_LGPO and Apply_LGPO_Delta utilities for managing Local Group Policy Objects.

Note that these are all now Visual Studio 2008 projects.

[Update Jan 15 2010: new versions released -- see the LGPO Utilities page]

New and Updated Local Group Policy Utilities

Aaron Margosis — Tue, 15 Sep 2009 17:30:00 GMT

A customer requested an addition to the local group policy toolset posted on the FDCC blog. While working on the new utility, I needed to upgrade the other two. The full set is attached to this post, with documentation. The source code for all of them is attached to a separate post.

The new utility, ImportRegPol, takes a registry policy file (registry.pol) as input. It can import its contents into the local group policy of the local computer (Computer or User configuration), or simply read it and output Notepad-editable text that can be consumed by Apply_LGPO_Delta.

While working on it, I discovered and corrected subtle shortcomings in Set_FDCC_LGPO and Apply_LGPO_Delta. The main shortcoming had to do with when a value or set of registry policy values were to be deleted: if the settings were present when Set_FDCC_LGPO or Apply_LGPO_Delta was run, they would be deleted, but those deletion “commands” were not saved in the policy store. So, if the settings were to be reintroduced, gpupdate from local policy would not remove them. The new implementations insert the deletion “commands” into the policy store so that they can be applied whenever policy refreshes. This required extending the input file syntax for Apply_LGPO_Delta and the log file output for Set_FDCC_LGPO, both of which have been bumped to v2.0.

While I was at it, I upgraded those utilities to Visual Studio 2008 and enabled ASLR and DEP. In addition, the new version of Apply_LGPO_Delta does not perform an OS check, so it is no longer restricted only to Windows XP and Vista, and will run on any supported version of Windows. Set_FDCC_LGPO still runs only on XP (SP2 or higher) or Vista (RTM or higher), because NIST hasn’t defined FDCC settings for any other versions of Windows.

Here is more information on the new ImportRegPol utility:

ImportRegPol

ImportRegPol is a non-interactive tool that imports the settings from a Registry Policy (registry.pol) file into the Computer or User configuration of the local group policy of the current computer. It can also parse a registry.pol file and produce an editable text file that can be consumed by Apply_LGPO_Delta v2.0.

Introduction

Administrators frequently apply policies by copying registry.pol files into the Group Policy folders. This technique is not supported by Microsoft, and has the unfortunate side effect of destroying any previously existing policies. ImportRegPol reads the reference policy file and uses supported application programming interfaces (APIs) to add settings to local policy.

The format of registry policy files is a documented, binary file format, normally produced by Group Policy editors such as GpEdit.msc. However, there aren’t any good viewers or editors for directly manipulating those files. For this reason, the Apply_LGPO_Delta utility uses a custom, Notepad-editable text file format to define specific changes to apply to local group policy. The log file format produced by ImportRegPol is compatible with Apply_LGPO_Delta v2.0. ImportRegPol can be run in a “parse-only” mode to read a registry.pol file and produce an equivalent input for Apply_LGPO_Delta.

The utility requires administrative rights to import policies, but does not require administrator rights for parse-only mode. Note that the in-use registry.pol files in the GroupPolicy folders can be used for input only in parse-only mode.

Command line syntax and usage:

The ImportRegPol command line syntax is described below. All parameters are case-insensitive. The command line must include -m or -u followed by the absolute or relative path to a registry policy file. All other parameters are optional.

ImportRegPol.exe –m|-u path\registry.pol [/parseOnly] [/log LogFile] [/error ErrorLogFile] [/boot]

-m path\registry.pol   [for Computer configuration] or

-u path\registry.pol   [for User configuration]

                        Path\registry.pol specifies the absolute or relative path to the input registry policy file (which does not need to be named “registry.pol”).

/parseOnly             Reads and validates the input file but does not make changes to local group policy. In conjunction with the /log option, can be used to convert a registry policy file to an input file for Apply_LGPO_Delta.

/log LogFile           Writes detailed results to a log file. If this option is not specified, output is not logged nor displayed. The logged results for the registry policy settings can be used as input for Apply_LGPO_Delta.

/error ErrorLogFile   Writes error information to a log file. If this option is not specified, error information is displayed in a message box dialog.

/boot                  Reboots the computer when done.

This utility is not a console app, so you won’t see a console window appear, and if you start it from a CMD prompt, it will run in the background – CMD won’t wait for it to complete. You can check in TaskMgr to see when it completes. If you want CMD to wait for ImportRegPol to complete, run the utility with "start /wait".

[Update Jan 15 2010: new versions released -- see the LGPO Utilities page]

FDCC Vista Application Development Requirements

cgreene — Wed, 08 Jul 2009 16:51:00 GMT

Overview

NOTE: This entry only focuses on the Windows Vista version of the FDCC and desktop applications.

Since its infancy, common themes have emerged which have delayed or prevented enterprise customers from deploying the FDCC. By the 80/20 rule, the two most common problems, in order, are:

1. Data and Settings Management

2. Application Installation

Customers have encountered other, smaller issues. But these two will cover 80% of the problems faced by applications when implementing the FDCC.

This entry will discuss the background of these items and how to best develop your application for the FDCC. It is primarily intended for developers, but system administrators can benefit too because some features of Windows will be discussed that can make your life easier.

This entry does not discuss UAC Virtualization. It assumes you are developing applications that will function entirely as a normal user.

Before we dive in, let’s discuss a little background and the purpose of the FDCC.

Why the FDCC?

The spirit of the FDCC is to provide a standard operating system image and settings, a common set of applications, and firewall for a non-privileged user community. This is the best way to secure an enterprise and ensure fundamental system integrity while reducing costs.

Users cannot be allowed unrestricted access to a system. There is no technical or business reason users should have elevated privileges to browse the internet, check email, or create and modify documents. Doing so provides an easy opportunity for malware to steal, destroy, or falsify data.

The foundation of the FDCC is Microsoft Windows Vista with NTFS. This is great news for those who have invested time and effort learning how to develop on the Windows platform. If you have developed on Windows in the private sector/commercial world, then developing on the FDCC will be an easy transition.

The FDCC, and Windows in general, is a system designed for multiple users and to isolate the actions of multiple users. Non-elevated users can only write to their own profile. They are not allowed to:

· Make system-wide changes

· View or modify another user’s profile

· Write or modify directories owned by the operating system containing binaries such as EXE’s or DLL’s

This helps keep any unintentional and/or malicious activity by one user from affecting other users of a system and spreading across the enterprise.

Unfortunately, MCS has worked with many applications that modify the default permissions and leave a machine more vulnerable to attack. Security can be completely undone by one application making a seemingly minor change.

Your job as a developer is to make sure you follow these best practices to maintain this default security.

Know your Users

The target audience for FDCC applications is no longer the workgroup. Gone are the days when you could assume a system administrator could physically visit the machines of your user community and install and configure application. Developers must make every effort to make sure their application can be deployed and configured in an enterprise environment with hundreds, thousands, or myriads of users.

Administrators are users too and first impressions last forever. Often the first experiences administrators have with applications are when they install the software on client machines. This experience can either be a good one or bad. The requirements put forth in this document ensure that administrators have all of the tools they need to do their job.

Data and Settings Management

Windows Vista provides the infrastructure to separate user data, user settings, and computer settings. Applications that use this infrastructure correctly offer the following benefits:

· Applications do not fail when run by non-privileged users

· Administrators or users can easily back up data and settings without needing to backup application or operating system files

· Multiple users can share a single computer, each with his or her own preferences and settings

· System administrators can enable Folder Redirection

· Applications are less likely to prevent Fast User Switching from operating correctly and efficiently

· Administrators can easily migrate user data when users get a new computer

History

Many applications make assumptions that their users would have administrative privileges and thus often try to write to protected areas of the operating system. Most commonly, these protected areas are the Program Files folder or HKLM. More generally, these areas include any resource in which normal users did not have write/modify access. Thus, on Windows XP many applications reported “access denied” error messages. Windows Vista introduced UAC Virtualization, but users often have no idea where the target redirection occurred. What’s more is that UAC Virtualization may be turned off in some organizations. If this occurs, applications commonly report “access denied” error messages just as they would were they running on Windows XP.

Several organizations maintained separate, logical drives for applications and data. Thus, it was common to find all application binaries installed on the C: drive and then a folder would be set up on the D: drive for user-created data. The idea was that the data would be safe on the D: drive if the C: drive ever crashed.

Also commonly found, were applications that installed custom directories on the root of the C: drive that contained application binaries and user-created data. The argument in favor of this practice was that applications and data could easily be migrated to new machines simply by backing up the directory on the old machine, and restoring it on the new on.

All of these scenarios remove flexibility from the system administrators and make network management more difficult. They raise the total cost of ownership for enterprises because:

1. Tools like the User State Migration Tool migrate user-created data, but it takes time and resources to develop and test each of these extensions. Often, several trial-and-error attempts must be made before it’s considered ready for production. Inevitably, something gets missed.

2. Administrators no longer have the flexibility to us folder redirection for user-created data.

3. While having the application isolate data into its own custom directory enabled users to share data, the negative is that this approach is a one-way street. It becomes difficult to separate data so that only certain users had access to it. It also makes using the application inside Terminal Services sessions practically impossible without major re-writing.

The following requirements will ensure that administrators have maximum flexibility and will help reduce their workload and allow them to administer by exception.

User-Created Data

User-created data is anything a user can store or retrieve at a later time. Obvious examples are Word, Excel, or PowerPoint documents. User-create files must be stored in the Documents folder or subfolder. The default Documents folder location for a typical Vista installation is C:\Users\<username>\Documents, but paths should never be hard-coded. Calling the Common Item Dialog will default to the Documents folder. Windows Vista also provides direct access to the Documents folder using the SHGetKnownFolderPath function passing in FOLDERID_Documents. For example:

PWSTR pszDocFolder;
SHGetKnownFolderPath(FOLDERID_Documents, 0, NULL, &pszDocFolder);
CoTaskMemFree(pszDocFolder);

On a typical installation of Windows Vista pszDocFolder would contain the string “C:\Users\<username>\Documents”.

Note: .NET Framework developers should use the System.Environment.GetFolderPath method with the Environment.SpecialFolder.MyDocuments parameter.

The benefits of using the Documents folder as the default location for data storage are:

· All users (including those with restricted account types) have write access to this location

· Users have one familiar place to organize and store all their data

· Data sharing is facilitated between applications because all applications using Common Item Dialog can easily access the Documents folder

· The Documents folder is an abstracted location and can be redirected to the network transparently by an administrator

· The Documents folder is available on the Start menu

Application-Created Data

Application-created data is used by the application to store application state, user preference, and temp files, etc. This type of data is typically hidden from users.

By storing this application-specific data in one of the several valid locations, you make it possible for multiple people to use the same computer without corrupting or improperly modifying each other’s data. The specification provides several valid locations and you are free to choose the location that works best for your needs.

A clear benefit to the developer is that can actually result in fewer lines of code. SHGetKnownFolderPath enables you to determine the correct location in which to store the user’s data and the user-specific application data.

Classifying and storing application data according to the guidelines in this requirement provides these benefits:

· It enables multiple users to share a computer and helps enable Fast User Switching.

· It enables business-related operations such as roaming, off-line storage, and allowing the operating system and its applications to be secured.

· It ensures a consistent and abstracted location for user data, enforces per-user separation of application data.

· It is one of the key factors in enabling remote use of the application.

This section identifies the valid file folders and the valid registry locations that applications must use for this data, and gives guidance on how to choose which of these locations are best used in different circumstances. The choice of valid locations to use is left to the software developer.

Classify application data into the following categories:

· Per user, roaming

· Per user, non-roaming

· Per computer (non-user specific and non-roaming)

NOTE There may be more than one category for the different application data stored by your application.

It is best to use application data file folders rather than the registry for storing application data in excess of 64K. The registry is an acceptable choice for small amounts of data. At installation time, try to store less than a total of 128K across HKEY_CURRENT_USER (HKCU) and HKEY_LOCAL_MACHINE (HKLM).

To comply with this specification, store application data files appropriately as either common or per-user. That is:

· In a subfolder of either the common application folder (identified by FOLDERID_ProgramData), or

· In the user profile folders: application data (FOLDERID_RoamingAppData) or local application data (FOLDERID_LocalAppData).

The subfolder to create to store user data files in is:
[company name]\[product name]\[version].

Using the Registry

Applications may also use the registry to store read/write application and configuration data.

· The HKCU registry hive is appropriate for storing small amounts of data (approximately 64K) and for policy settings that are per user.

· Avoid writing to HKLM during runtime, because limited users have read-only access to the entire HKLM tree by default. In addition, HKLM does not support roaming.

· Larger, file-based data should be placed in an application data folder. For example, Internet Explorer’s Temporary Internet Cache is stored within the file system of the user’s profile and not in the registry.

· At installation time, the application should not store more than a total of 128K across HKCU and HKLM.
Note that HKEY_CLASSES_ROOT is excluded.

Using Application Data Folders

Once you have decided how to classify your data, you can use SHGetKnownFolderPath to retrieve the corresponding folder locations.

The KNOWNFOLDERID values described here provide a consistent, unified way to access the physical paths to the desired folder locations, independent of the operating system. The preferred API is SHGetKnownFolderPath. To access the path for application data, applications should call SHGetKnownFolderPath with the appropriate KNOWNFOLDERID and then append [company name]\[product name]\[version] to the returned path. Specifically:

PWSTR pszAppData;
SHGetKnownFolderPath(
FOLDERID_RoamingAppData, 0, NULL, & pszAppData);
CoTaskMemFree(pszAppData);

On a typical installation of Windows Vista pszAppData would contain the string “C:\Users\<username>\AppData\Roaming”.

Note: .NET Framework developers should use the System.Environment.GetFolderPath method with the Environment.SpecialFolder.ApplicationData parameter.

When storing application data in the user profile, applications must use the following hierarchy under the Application Data file structure:

FOLDERID_RoamingAppData\
[Company or Organization Name]\
    [Product Name]\
      [Version]\
        [File or Folder]

Data Type	KNOWNFOLDERID	Folder Location
Per user, roaming	FOLDERID_RoamingAppData	[user profile]\AppData\Roaming
Per user, non-roaming	FOLDERID_LocalAppData	[user profile]\AppData\Local
Per computer (non-user specific and non-roaming)	FOLDERID_ProgramData	C:\ProgramData

To comply with this specification, applications must classify and store data appropriately as either common or per-user. That is, either FOLDER_ProgramData or one of the user profiles: FOLDERID_RoamingAppData or FOLDERID_LocalAppData.

FOLDERID_RoamingAppData

This folder will be enabled for roaming with the user profile. Use this folder to store all user-specific application preferences. For example, if a user can specify a custom dictionary to be used in the application, you would store it here. That way, if a user roams from computer to computer, the dictionary will roam with him or her. This also allows other users to have their own custom dictionaries.

FOLDERID_LocalAppData

This folder is for application data that does not roam. As it is still part of the User profile, this is still per-user information. Application data that is computer-dependent, such as user-specified monitor resolution, must be stored here.

This data must not roam because different computers are likely to have different monitors. In addition, large blocks of data that can easily be recreated and temporary files must be placed here to minimize download time that is incurred when roaming.

EXAMPLE Internet Explorer keeps its cache of downloaded .html/.gif pages here so that they don’t roam with the user. However, the smaller cookie and history lists are stored in FOLDERID_RoamingAppData so that they do roam.

FOLDERID_ProgramData

This folder should be used for application data that is not user specific. Note that a limited user will only have read privilege for files in this folder, except for the files that user created. If users need to have write access to the common files, then during installation the application must create a sub-folder of FOLDERID_ProgramData with “Modify” privilege for appropriate user groups.

EXAMPLE An application may store a spell-check dictionary, a database of clip art or a log file in the FOLDERID_ProgramData folder. This information will not roam and is available to anyone using the computer.

Additional Considerations

· Files may be shared in the application data (FOLDERID_LocalAppData, FOLDERID_LocalAppDataLow or FOLDERID_RoamingAppData) folders. Multiple computers may use them simultaneously with different instances of the application. The data may also be used by multiple applications, for example, applications in a productivity suite.
Applications should get a write exclusive on the file only when absolutely necessary. For example, applications using CreateFile should only specify GENERIC_WRITE when a write is required, but they should always set FILE_SHARE_READ.

· Paths returned by SHGetFolderPath are valid Win32 file system names that may contain spaces and may be in the universal naming convention (UNC) format.

· PathAppend() and PathCombine() APIs can be used to concatenate the relative path information onto the paths returned by SHGetFolderPath. For example:
PathAppend(szAppData, "Company\Product\File.txt")

· By default, all users can write to the Users\Public\Documents location (FOLDERID_PublicDocuments).

Application Installation

The best way to package applications is using the Windows Installer format. Windows Installer is the native application installation engine in Windows Vista. It provides the following benefits:

· Applications can be inventoried using Windows Installer

· System administrators can selectively change how and which features will be installed

· Applications have the ability to self-heal

· It enables applications to separate per-user and per-machine installation tasks

· Applications can provide silent or unattended capabilities often with little effort on the developers part

· It enables system administrators to easily choose how the app is deployed (Group Policy Installation or Configuration Manager installation)

· A properly formatted MSI package is transactional. It either completely installs or completely fails. It never leaves the system in an unknown state.

· It automatically supports UAC

· There is already a large ecosystem of applications packaged in the Windows Installer format. Thus, the learning curve is minimal or non-existent for most system administrators.

See the following links for more information on Windows Installer:

· Overview of the Windows Installer Technology

· Developer Story Windows Installer

History

Once upon a time, it was common to find organizations with administrators running around the office from machine to machine, installing and configuring applications. Many lines of business (LOB) applications were limited to a finite set of known users and so it was understandable to train a few people how to administer them. They were built with enough functionality to meet the needs of the end user, but the burden of installing and configuring the applications was largely left to the administrators by following a long series of manual steps on each user’s desktop. The unfortunate reality is that creating a solid installation package was mostly an afterthought for many application developers.

The worst offenders had no installation package or the installation package was nothing more than a scripted xcopy. Administrators were instructed to create a directory, copy EXE’s and DLL’s, create registry keys and shortcuts before the application could be used. Any missed step or instruction not followed perfectly lead to a partially functioning application or, worse, a non-functioning application. Repeatability of the application installation was low and configuration management became more difficult. But even if an administrator got an application installed properly, there were often other difficulties running the apps.

Many applications stored user-created data and application data in the same directory as the application directory. If these applications were installed to Program Files, normal users were denied write and modify access. Thus, even if users weren’t responsible for installing and/or configuring their applications, they were still often granted elevated privileges because some applications simply would not run otherwise. But because users had full control over their PC’s, it created an unmanaged situation and administrators often had no idea how each machine was configured. Worst of all, users can easily download – without even realizing it—malware. This is an invitation to hackers and has historically been the cause of several security breaches in enterprise networks.

Many applications are also commonly installed to non-standard locations on the root of the hard drive, such as C:\AccountingApp. This was thought to solve the problem of giving users administrative privileges because users were able to read/write/modify. Plus some developers argued that it made migration from one machine to the next easier because a single directory could be copied from the source machine to the target machine. But it presented other problems.

Any user with write/modify access to the application folder would be able to replace the application binaries. But remember – Windows and the FDCC are designed to isolate multiple users and their actions. Thus, allowing users write/modify permissions to binaries shared by multiple users could allow someone with malicious intent to view or modify another user’s profile or make system-wide changes. More details and consequences of which can be found in the Changing access control on folders vs. files post.

In addition to being a security vulnerability, this approach also made it more difficult when users were upgraded to a new machine and data had to be migrated. Many development teams reasoned that application data is all stored in one place so it’s easy for an administrator to a folder from one machine to the next. True, but only if the administrator has to do it one time. And it completely ignores the security aspect. But security aside for the moment: what happens when there are hundreds or even thousands of machines and/or users? Administrators must rely on tools to help them migrate data like this.

Tools like the User State Migration Tool automatically migrate data for several hundreds of applications. And it is extensible so that administrators can migrate LOB apps. But it takes a lot of resources to configure USMT correctly. So what happens when there are hundreds or even thousands of applications?

Installation Directory

Applications must always target the Program Files folder by default. Applications that install to a subdirectory of this folder inherit the restricted permissions from the parent by default. Normal users are given read and execute permissions to application binaries. But they are not allowed write or modify permissions.