The horse has already bolted

 

A while ago (yes, I'm very slow) Ivan had a couple of blogs about removing the ability to turn off CAS in the runtime (here and here). Whilst I am sure the CLR team has some good reasons for doing so, many of the comments on the entries exhibit a common misunderstanding about security (well, about lots of things really). The idea is that if you shut off one avenue for the "bad guys" to get their dirty work done, then you will have made the world a better place. Sounds like a reasonable idea, right? Well it would be, except for two small problems:

1) The thing you are shutting off is inaccessible to the bad guy unless he already owns your machine; and

2) Shutting off one way doesn't help when there are many other avenues to choose from

The suggestion is to remove the ability to use the command-line:

caspol -s off

or to make the equivalent API call:

System.Security.SecurityManager.SecurityEnabled = false

and to possibly replace it with a registry key instead.

Most of the user comments want the ability to turn security off completely removed so that malicious code can't run rampant on your system, but the problem is that if a hacker can already run caspol -s off on your machine then two things are true:

1) They're running arbitrary code on your machine

2) They're running as a highly privileged user (Administrator) on your machine

Both of these things mean that the hacker has already won! Who cares if he can turn security off or not; he's already 0wnz0r3d j00. Let's say that the caspol switch was removed; there are at least three other things the hacker could do to achieve the same goals (assuming, of course, that the code already running rampant on your system isn't already doing all the damage):

1) Replace / patch the CLR itself to bypass all security checks. You probably only have to tweak a couple of bytes in the right CLR binary to completely bypass all security checks; anyone running arbitrary code as Administrator can replace any system file on your machine with a patched / hacked / back-doored version

2) Update policy with a blanket rule to trust all code from every location with FullTrust. They can't turn security off any more, but they sure as heck can cause the security system to grant all code FullTrust:

caspol -en -cg 1 -levelfinal on

(DO NOT enter that command line into your system! It will let all code - even code from the internet - have full control over your system)

3) Avoid using managed code! Well duh! If the CLR security system is going to enforce security policy, then just run native code instead :-) Even script code (VBScript / JScript) running under WSH has FullTrust on any normal system

The problem is that you're trying to shut the barn door after the horse has already bolted. It's like asking your locksmith to remove the ability to unlock your front door from the inside --once the burglar is inside, she doesn't need to unlock the door anymore! All it does is make life harder for you (the home owner) since you now have to climb out the window instead of going out the door, and it doesn't really stop the bad guys from getting in anyways (you left the window open on your way out...)

Does it make sense to reduce the discoverability of the feature so that curious or naive users don't accidentally make their machines insecure? That's quite possibly a good idea. An average user probably shouldn't be able to turn off security by simply copying text from a web page or e-mail message into the Start -> Run dialog, because it might be easy to socially engineer them into doing so (or they might forget or not know how to turn it back on later).

But don't fool yourself into thinking that it improves the real security of the system. The horse has already bolted.