DotNet UserControls Restricted in IE8

In the past, Internet Explorer supported a really easy way to host .NET UserControls in HTML. These controls worked much like ActiveX controls, but because they ran with limited permissions, sandboxed by the .NET Framework, they would download and run without security prompts.

It was a very cool technology, but didn’t see much use in the real-world, partly because the .NET Framework wasn’t broadly deployed when the feature was introduced. Later, ClickOnce, WPF, and other technologies took center stage, leaving this relic around, mostly unused beyond developer demonstration pages and tutorials.

Until the summer of 2008, that is. At BlackHat 2008, security researchers Dowd and Sotirov revealed that the loader for UserControls enabled bypass of memory-protection mechanisms, meaning that browser vulnerabilities could be exploited with improved reliability.

While Protected Mode and other features are useful to constrain the impact of vulnerabilities, DEP/NX and ASLR memory protection are a very important part of the overall mitigation strategy. After investigating the options, crawling the web to examine use “in the wild,” and consulting with the .NET team, we elected to disable UserControls in the Internet Zone by default for IE8.

Now, since the UserControls feature was first introduced, IE’s security settings allowed disabling ".NET Framework-reliant components," but the existing settings were overly broad. They controlled not only UserControls, but also out-of-process features like ClickOnce. Because out-of-process use of .NET is not a vector for memory-protection-bypass in the browser, we chose to create a new URLAction that would restrict only use of UserControls.

IE8 introduced the URLACTION_DOTNET_USERCONTROLS setting, which allows .NET UserControls to load only from Intranet and Trusted pages by default. On Internet pages, the controls are blocked as if they had failed to download. This setting is not exposed in the Internet Options dialog or in the Group Policy editor; it can only be controlled via the registry keys.

Reducing attack surface by removing an extensibility feature was painful decision, but ultimately a good one. Not long after we made this change, the new URLAction would cleanly block exploitation of a browser vulnerability that was unveiled at the CanSecWest security conference.

IE8 includes a number of important security features and defense-in-depth changes that raise the bar against the bad guys. If you haven’t upgraded yet, you should do so today!