次の方法で共有

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.

Comments

  • Anonymous
    March 06, 2004
    The comment has been removed
  • Anonymous
    March 07, 2004
    The comment has been removed
  • Anonymous
    March 07, 2004
    Andrew - totally agreed that it makes sense to protect people from themselves. It's much easier than fooling someone into lowering their IE security settings because you can cut+paste into the "Run" dialog... it takes a bunch of manual steps to change IE settings.
  • Anonymous
    March 13, 2004
    You are of course right that security is not just turning things on and off. However, I don't think people who commented misunderstands security. People are complaining because of Microsoft's history. There still are way too many undocumented "features" that lead security holes in Windows.
    Ivan's entry smelled at least for me that may end up with "they did it again!". Making halls invisible is bad no matter what. Having other avenues is just another problem. For now, even when CAS is turned off (by accident or not does not matter here) there are no way other than peeking into registry to know things went wrong about CAS. That is of course the problem and needs to be more flushingly visible.
  • Anonymous
    April 16, 2004
    The comment has been removed
  • Anonymous
    April 23, 2004
    The comment has been removed
  • Anonymous
    May 10, 2004
    The comment has been removed
  • Anonymous
    July 16, 2004
    In response to Nicole's comments ... You're right that disabled CAS environment is not very secure, and the CLR team has been looking at some ways to address this situation, however I feel that your concerns won't be addressed by simply disallowing CAS to be turned off.

    Almost all of your concerns revolve around the assumption that the default CAS policy is still in effect. However, this may not, and quite possibly is not still the case. Even if the default policy is in effect, there's nothing stopping FullTrust code that runs on your local computer from accessing your private members. Even if your assembly was not granted FullTrust, it's very easy for me to whip up an assembly that lives on the local machine and assert some permissions, then reflect over your code.

    Basically, once you've supplied your code physically to an admin to put on their machine, its game over for you. If you need to defend your IP, you must host on a machine you control, and allow access through another mechanism.
  • Anonymous
    July 16, 2004
    The comment has been removed
  • Anonymous
    July 16, 2004
    Nicole, you are trying to win an unwinnable battle here. If a malicious user has complete control of the system, then they can do anything they want. It isn't your system any more.

    The best the CLR can do is protect your code from within the confines of the managed CLR environment itself. As soon as you go outside of the managed environment, it's game over. For example, the hacker just uses unmanaged code to twiddle the in-memory bits that represent your StrongNameLinkDemand so that it will succeed.

    Or, they just ILDASM your code, remove all the securiyt checks, and ILASM it back again.

    In fact, if the attacker has full control of the system, what are you trying to "protect"? THEY DON'T EVEN NEED YOUR SOURCE CODE ANY MORE!

    What does it mean to "misuse low accessibiliy members" if the attacker is running with FullTrust? There's nothing your code can do that they can't do themselves.

    I don't understand the kinds of scenarios you are presenting. As Shawn says, the ONLY way to protect against this is hardware (physical) isolation -- expose a web service ON A MACHINE YOU CONTROL and stop worrying about attacks you cannot hope to stop ;-)
  • Anonymous
    July 23, 2004
    The comment has been removed
  • Anonymous
    July 24, 2004
    If the administrator can't be trusted, fire them.

    Maybe I need to write a blog about basic security priniples...

    Until then, everyone should read this:

    http://www.microsoft.com/technet/archive/community/columns/security/essays/10imlaws.mspx

    and this:

    http://www.microsoft.com/technet/archive/community/columns/security/essays/10salaws.mspx
  • Anonymous
    May 10, 2006
    You've already lost the game.