Interception/Unity pattern and security issue

Topics: Policy Injection Application Block
Oct 14, 2011 at 9:46 AM

I am using interception with unity container. This allows me to build, deploy application on productive environment, and using configuration file change its behavior.
The problem is somebody could inject 3th part code.
One of requirements is not to allow any code except that which was built in version which was send to client. (This is out client requirement).

How to achieve it in simplest way?
- does unity container support such filtering?

- maybe dll strong signing? But how to combine it with interception/unity

- any other suggestion?

I will be grateful for pointing topics I should dig into.

Oct 14, 2011 at 12:07 PM
Edited Oct 16, 2011 at 8:15 PM

When you run your code at a machine you have no control over, it is always possible for someone to interact with that and change the behavior of your program. Even without interception. This is especially easy for a managed application, such as .NET applications, but it is even possible with applications written in unmanaged code (such as C++). So what are your exact requirements?

Oct 14, 2011 at 12:52 PM

Let's say that app consist of few assemblies. Each is strongly sign by code supplier.
App code creates objects only from signed assemblies without interception/unity ...

I don't know how to call it. So let's say that all time we are doint it in this way:

interface IMyInterface ....

class MyObject : IMyInterface ....

IMyInterface myObject = new MyObject();

Is it still possible to inject 3th part object to myObject without rebuilding dll's?

 

The requirement are to:

- deliver msi (dll package) with finished app.

- provide mechanizm to check app instalation integrity (my idea is to use Trusted Publishers on Windows Server 2008 R2: our certificate would be added as trusted certificate and code will be signed with this certificate).

- guarantee that unity/interception can be used to switch/modify/inject... as we implemented in delivered package.

 

Can unity/interception be used to inject 3th part code to such app?

 

This requirement exist because external company is checking out client, and they do not trust administrators.

Also this external company is checking our code, but of course somebody can inject something after we deliver app.

Let's say that they arrive on monday. Check server certificates and after a while they are sure that software is ok.

 

Any better idea to solve this problem?

Oct 16, 2011 at 5:04 AM

There are some options. First, interception can be done completely through code, so you can just not use the config file.

However, if you don't trust the administrators of the system, the game is already over. If you were using the config file, then you would require write access to the file system to change the configuration and use Unity to inject code. But if they have write access to the file system, THEY HAVE WRITE ACCESS TO YOUR EXECUTABLES TOO.

Yes, you've set it up to only run your signed code. If you have write access to the disk, you can replace the configuration with one that runs your own signed code. Then recompile with whatever signature you've got. The only bulletproof option here would be to ship them an entire machine with a cabinet that's glued shut with an explosive that destroys the drive if the case is opened.

If your client is insisting on this, then you need to sit down with them, work out a threat model, and figure out what they're actually trying to protect against.