Didier Stevens

Tuesday 12 February 2008

Fine-Grained Control over Code Access Security

Filed under: .NET — Didier Stevens @ 7:12

With Code Access Security (CAS) in the .NET Framework, Microsoft introduced a whole new security layer on top of Windows security.

If you need to temporarily disable CAS, for example during a debugging session, you can use the caspol utility. The command caspol -security off will disable CAS enforcement as long as the caspol tool is running (this is true for .NET 2.0 and later). If you are interested in the implementation details: it’s done via a mutex.

One issue with caspol -security is that its effect is system-wide. If you need to unit test .NET assemblies by repeatedly toggling CAS enforcement, the caspol utility lacks some control. Not only your assembly will be affected by the toggle, but every other assembly on the machine. And the setting only takes effect for assemblies started after the caspol command was issued. When you re-enable CAS enforcement, it will only affect new processes. Running programs continue to ignore CAS, they have to be restarted for the new setting to take effect.

My new utility, CASToggle, gives you more control over CAS enforcement. First of all, it operates on a per-process basis. You have to specify the process ID of the program for which you want to switch CAS enforcement. Second: the effect is immediate, you don’t have to restart the program.


  • castoggle 123 1 – this will immediately disable CAS enforcement for process 123
  • castoggle 123 2 – this will immediately enable CAS enforcement for process 123

CASToggle controls CAS enforcement by directly manipulating the appropriate variable in the process memory of the targeted program. So it’s best to use CASToggle only for testing purposes. When you look at the source code of CASToggle, you’ll notice that most of the code is there to ensure that it manipulates the correct memory location. For example, it will check the version of mscorwks.dll before it attempts to access the process memory. But if the DLL is not loaded at its base address (e.g. because of ASLR on Vista or Windows 2008), the program could manipulate the wrong memory location and cause the program to crash. Unknown DLL versions cause the tool to break-off without accessing the process memory. I’ve tested CASToggle on Windows XP SP2, Windows 2003 and Vista with different versions of .NET (2.0 and up).

To see CASToggle at work, take a look here on YouTube, hires (XviD) version here.

Oh, and there is one more thing that differentiates CASToggle from caspol, but I’m not going to tell you right now. Can you figure it out? Post a comment! First one to figure it out gets the honors! 😉

Blog at WordPress.com.