Hosting AddIns - The problem with untrusted code
time to read 2 min | 350 words

Let us assume that we need to load some code, potentially un-trusted / hostile into our application. The runtime has a lot of functionality to offer us in this regard, we can segregate the strange code pretty well in a low privilege AppDomain, but we can't protect ourselves from the AddIn killing us.

There are two simple ways an AddIn can kill the host application, without the host being able to do something about it. Both are very easy to do by mistake, unfortunately.

The first is to simply throw an unhandled exception from a thread and the second is to cause a stack overflow.

Both are considered as fatal errors and can not be recovered. In fact, in the stack overflow case, you can't ever get any information about what exactly happened. Here is a simple malicious addin that cannot be recovered or traced:

public class MaliicousAddin : MarshalByRefObject
{
    public void Execute()
    {
        new Thread(delegate(object obj)
        {
            Overflow();
        }).Start();
    }

    private void Overflow()
    {
        Overflow();
    }
}

This puts us in somewhat of a problem. We want to have a way to recover from malicious (or badly written) add ins. There are two ways that I have found to do so, both are unsatisfactory. The first is to simply run the AddIns in another process, which means that the add in can still crash the process, but the host is actually running on another process, and so not affected. The second is to play with the CRL Hosting API in order to modify the default runtime behavior. This option is probably out if you plan on hosting your application somewhere (like IIS, for example).

Any other options?

Tweet Share Share 22 comments
Tags: