MS Word Exploit - Administrator Rights - Oh my...
Some areas of the net are in a flap about the MS Word exploit that has been the focus of some publicity recently. Some sites are even advising that we should consider dumping MS Word in preference to OpenOffice.
Come on guys. We shouldn't even be thinking about fighting this thing by moving to a different programme. Why? Because it does not address a core problem. The thing about this exploit is that it will only succeed if the user has administrator privileges. We all know that we shouldn't be running our machines with administrator privileges, but all of us also have clients that absolutely insist that they must run as admin because a mission critical application will not run without it.
So, what can we do under such circumstances? How do we protect our clients from this exploit and other admin dependant exploits if they have a mission critical application that will not run without administrator privileges?
Preferred option - reduce their rights anyway, and use RunAs - stick a shortcut on their desktop that grants only the mission critical application administrator privileges:
Your user still isn't happy? They just don't like non-admin? They're telling you its *their* machine and they want administrator rights? Well, short of washing your hands of any responsibility and walking out the door never to return, there is another trick you can use. What if you could let your stubborn client run as admin, but bump down particular applications to limited user rights *at the same time*? Sound interesting? Read on... :o)
Michael Howard has posted an article to the Security Developer Centre that is of especial interest to those who are faced with "I must be Admin" users who also wanted to be protected from the Word exploit:
You'll note that by using Software Restriction Policies you can stop a programme from running at all, or force it to run as a limited (basic) user. If you want to really lock things down you can use Constrained or Untrusted.
There is one very important limitation to this trick that we must be aware of. Software Restriction Policies are path dependent. That is, you must set a specific target path to the application for this to work. If, for example, an executable is moved or copied to another directory, the restriction policy will fail.