Microsoft has released .NET Framework 3.5 SP1 which includes a security change from previous versions allowing to run managed applications from network shares.
According to Microsoft, one of the .NET Framework 3.5 SP1 features is:
Managed applications that are opened from network shares have the same behavior as native applications by running with full trust.
In the past, one could not run managed code from network shares due to security reasons. That feature was introduced in .NET from the beginning to prevent security attacks coming from network locations. The feature did not resolve the respective security threats because unmanaged code always was allowed to run in such a circumstance.
A pool organized by Brad Adams, Program Manager at Microsoft, shows that many people would like to have the possibility to run managed code from network shares. Microsoft responded to the general request enabling the feature in .NET 3.5 SP1.
Vance Morrison, Architect on the .NET Runtime Team, comments on the security change:
We made a mistake. In 2001 we believed we are the avant-guard in making things 'secure by default' and thus biased our decisions believing that we would eventually 'plug' the hole of unmanaged code running from a network share. We also did not appreciate the pain this decision would cause.
However over time, we realized that we were naive. The cost/benefit of changing the behavior of unmanaged code is simply too high. Moreover it also become clear that for security to work, it must be simple, which means treating cases uniformly. Thus if you want to disallow launching exes off the network you should not have one way of doing it for managed code, and a completely different way for unmanaged code.
Vance also downplays the security risks introduced by the change:
For those of you who are concerned that we have opened security holes by doing this, we have tried to be VERY careful not to do this. The basic rationale is that we are not opening any holes that were not already there because Windows allows non-managed exes to run from a network share.
Shawn Farkas, a software engineer on the CLR team responsible for the cryptography classes, explains how the new feature works:
The core of this change is a modification in how we assign evidence to network launched applications. When we see an .exe launched directly off a network share, rather than giving that .exe Zone evidence of LocalInranet, we instead give the .exe Zone evidence of MyComputer. This causes the .exe to match the default MyComputer code group rather than the LocalIntranet group, and in default CAS policy that code group grants FullTrust.
For those who want to forbid running managed code from network locations Shawn advises:
You can set the DWORD registry value LegacyMyComputerZone to 1 in the HKLM\Software\Microsoft\.NETFramework registry key.
The assemblies will receive the rights to run in the following scenarios, according to Shawn:
- Any managed .exe which is launched directly from a network share
- Any assembly in that .exe's process which is loaded from the same directory as the .exe itself was.
In the next scenarios assemblies will not receive the rights to run:
- Assemblies loaded from a subdirectory of the share where the .exe was launched from
- Assemblies loaded from shares other than the one where the main .exe was launched
- Any assembly loaded on a machine with the LegacyMyComputer registry value set to 1
- Any assembly loaded into a CLR host, including assemblies loaded into Internet Explorer as controls.
- Any assembly loaded from shares by an application that was launched from the "real" MyComputer zone.