Major Security Change in Service Pack 1


Secure ASP.NET


Major Security Change in Service Pack 1


By Don Kiely


Service Pack 1 for Visual Studio 2008 and .NET Framework 3.5 will soon be upon us, and may even be released by the time you read this (Microsoft will only say that it will be out this summer ). There are a lot of nice goodies in this release, including dynamic data, data services, and a wide variety of fixes. Microsoft is once again breaking with their oft broken promise to not include new features in service packs, but I ll leave a discussion of the pros and cons of this to others.


Surprisingly, the service pack includes a major change that significantly degrades security in favor of convenience. Despite its long and loud trumpeting of trustworthy computing, they are changing the default permission set for programs run from the local intranet to run with full trust. That means that by default when you load an application from anywhere on the local intranet it is automatically granted full trust. The upshot of this is that it will be easier for malware to propagate across the network. If an EXE or DLL on the network becomes infected, nothing will prevent it from infecting other machines.


I first wrote about this issue back in November 2007 in this column when Microsoft was floating trial balloons about the change. I included a link to the poll on the issue in Brad Abrams blog. Unfortunately, the comments there were mostly in favor of convenience over security and those were the voices Microsoft listened to. This shows that you can blame Microsoft all you want for security flaws, but some of them are at the request of its customers. Sigh.


But what is most disturbing about this change besides the degradation in security is how Microsoft implemented it. With the default settings, say that you run a program from the local network. You d expect that it would get LocalIntranet evidence, right? Nope, wrong guess! Even though it is on the local intranet, it gets the MyComputer evidence. So now administering permissions becomes harder. You can tighten down the permission set for the LocalIntranet zone, and that will have no effect on the actual permissions a program on the local intranet gets. Even worse, the names of zones are now out of sync with what they apply to. Not good.


Microsoft helpfully lets you retain the legacy settings by, get this, a registry setting change. Simply set the registry value LegacyMyComputerZone to 1 in the HKLM\Software\Microsoft\.NETFramework registry key. Oh, and apply that setting to every machine on the network that has the .NET Framework installed. Yikes.


To be fair, there are some limitations to the change. DLLs used by the EXE only get full trust if they are in the same directory as the EXE. If the DLLs are in any other directory they are only partially trusted. You ll have to go run executables in other directories to get infected by DLLs in those directories. The change doesn t apply to hosted applications, such as SQLCLR code that runs in SQL Server 2005 or 2008. Nor does it apply to hosts like Internet Explorer.


You can read more of the implementation details on Shawn Farkas blog.


Security degradation in the name of convenience. Never a good thing.


Don Kiely, MVP, MCSD, is a senior technology consultant, building custom applications as well as providing business and technology consulting services. His development work involves tools such as SQL Server, Visual Basic, C#, ASP.NET, and Microsoft Office. He writes regularly for several trade journals, and trains developers in database and .NET technologies. You can reach Don at mailto:[email protected] and read his blog at





Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.