Share via

DotNet UserControls Restricted in IE8

  • Article

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!

thanks,

-Eric

Comments

  • Anonymous
    November 03, 2009
    Does this apply to any custom .Net control developed for client-side, or just to UserControls (Windows Forms controls)? Do the object tag symantics for all custom controls revert to ActiveX-style, then?

  • Anonymous
    November 03, 2009
    @William: The simple way to understand the difference is as follows: If you invoke your object like so: <OBJECT classid="mydotnet.dll#Namespace.Class"> It will no longer load. On the other hand, if you've exposed your control as a COM object, and thus invoke it with a GUID as follows: <OBJECT classid="{AABBF33-C551-11D3-89B9-0000F81FE221}"> then your control will be treated as a normal  ActiveX control. The reason is that the latter syntax doesn't bypass the traditional ActiveX security measures; the user must download your control and install it, etc. That mitigates the DEP/NX issue because if the user is willing and able to install malicious code, all bets are off.

  • Anonymous
    September 03, 2010
    I find that unfortunate: I wrote a user control to run in the 'Internet' security zone, expressly so that I could demonstrate it by including it on a web page. You can see the demo at www.modeltext.com/.../demonstration.aspx ... but, using IE8, you now need to declare that as a 'Trusted site'. > That mitigates the DEP/NX issue because if the user is willing and able to install malicious code, all bets are off. After skimming the paper which describes the exploits, I thought that the potential problem isn't the possibility of malicious code in the .NET user control: rather it's the fact that a user control is loaded at a semi-predictable base address, which means that it can then be profitably overwritten by malicious code that's running elsewhere.

  • Anonymous
    September 03, 2010
    I'm glad I could help eliminate your confusion, Christopher.