Unity Security Hole?

Aug 31, 2009 at 4:45 PM

We have a WPF application that uses Unity extensively.  We have a number of assemblies we reference that contain our View Models and Managers.  The assemblies are all strong named.  The app works fine.

But an industrious hacker can do the following:

1.  Create a new DLL that implements one of the Interfaces (i.e. our ISecurityManager.IsAuthorized interface that controls which buttons on the app a user can see)

2.  Alter the app.config to change where Unity is getting the Security Manager to point to the copy they have created, and remove the Public Token from the config so their dll doesn't have to be in the GAC.

3.  Run the app.  It now picks up the new dll and the new SecurityManager with it's new implementation of the IsAuthorized method.

Is it just me, or is this a really bad thing?  I realize that this is exactly what Unity is intended to do, but my intention in using Unity is to make the development easy, not make hacking easy.   This scenario makes me nervous about using DI on any client deployed application.

Thoughts?

Aug 31, 2009 at 5:01 PM

Gaining access to the app.config to implement such a hack would mean your IIS Server security has been comprimised and you have much bigger problems - in which case none of your applications are secure (regardless of the technologies used).

Inadequate physical security would make me very nervous - if done properly the technologies used should not be an issue.

Aug 31, 2009 at 5:50 PM

As I said in my note, this is a WPF Client application, not an ASP.NET application, so access is quite easy for any user.

Aug 31, 2009 at 6:12 PM

I see says the blind man ;)  My knee jerk reaction (without applying a risk analysis and understanding the environment) would be to ensure assemblies could not be easily replace, i.e., programmatically configure the application versus using a config file.   I'm a die-hard Unity coder so I'd find a way :)

Aug 31, 2009 at 6:52 PM

Simple fact is you can't trust the client machine, period. Hacking the app.config file is pretty much the same as replacing the exe or dll. Either the program's directory is properly acl'ed and the user is running under restricted permissions or they aren't. Using Unity doesn't actually expose any more risk here.

Heck, if they've got physical access to the machine nothing stops the determined hacker from running ILDASM, tweaking the assembly, recompiling and replacing your exe wholesale. Or even hacking the runtime dll's themselves.

 

Aug 31, 2009 at 8:50 PM

billk - good idea.  We'll do this.  The config files were getting a little out of hand, especially when trying to support 4 environments (DEV, TEST, QA and PROD) where the Unity config rarely changed for any of them, but other app.config settings did.  We had a static 'UnityFactory' that loaded the config once, but we also have 4 dll's (View Models, Managers, Models, Views), that now needed their own UnityFactory in their own namespace (to avoid circular references), it gets a little complicated.  Trade offs, I guess.

Chris, point taken and appreciated.  I can't think of a reasonable counter to your arguments.  Intuitively, it seems that editing a config file is much easier than ILDASM, but you are correct in that once they can do A, they can do B, assuming some technical knowledge.  We're having a bit of a philosophical debate here in the office on this one; where do we stop worrying in the code, and let the OS / Network take over?

Aug 31, 2009 at 9:24 PM

I feel your pain..  I didn't have the QA environment but the DEV, TEST and PROD environment was enough to prompt me to come up with a better way because one missed configuration file (many many modules each with their own configurations) resulted in some tail-chasing.   I actually came up with a single config file, per environment, solution for enterprise applications.   In case you and your team are interested I provide webcast and blogs on the following project http://www.codeplex.com/SDMS  - the link for the "WCF, Unity and Configuration" (webcast) was the most fun - in this prototype I actually can control what implementation a WCF service interface will use from the main web sites Web.Config.