Allowing execution of extern interface implementations: what are the risks?

Question

from writing ABAP programs, the following methodology is known to me as an 'exit' to a program, for this reason I choose the names accordingly.

Suppose you, in .Net,

1) define an interface

namespace Exits {
    public interface Exit {
       int exitMethod(string s); // signature serves as example only
    }
}

2) provide some way to the user of your application to pass the name of a user written assembly ExitImplementation.dll and the name of a class, say myClass : exit, implementing the interface exit, to your application. E.g. as command line parameters or in some form.

You store the name of the user assembly in string assemblyName and the name of the class (including namespace) in string theImplementation and then load it an execute it:

3)

    Assembly assembly = Assembly.LoadFrom(assemblyName); 
         // assuming assembly is deployed by user into folder where application resides
    Exit theExitImplementation = assembly.CreateInstance(theImplementation) as Exit;

    int k = theExitImplementation.exitMethod("whatever");  

(First question, of minor importance: does this technique have a name outside of the ABAP world, and what is it called? :-) )

What I'd like to know is which risk are you taking by letting your application execute this user code (forgive me in case that's a naive questions, I'm still new to .Net). Let's say the output is only some message code needed to determine some message output to some log.

Assume as deployment scenario some company using the application for doing their business and some employee of that company writing the exit implementation. If that employee wants to cause damage, what would be at risk:

1. nothing but a wrong message in the log?
2. content of class instances of the application?
3. resources of the PC the application is running on?
4. worse?

It is my impression the answer is 4. isn't it? myClass gets the oppurtunity to execute and hence can basically do what any application can do which was started by the user who is running the original application. Are there means to prevent this?

If so: does it make any difference (if so, which), that the signature of the exit is fixed and that the input to the method cannot be changed in the method? This method by intention does not allow the type to be defined dynamically.

This method, also by intention, only allows input which cannot be altered. Assume the string argument is replaced by some other type which the caller could modify, like StringBuilder. Is this increasing the risk?

Are there more sophisticated (standard) techniques to reduce the risk with this approach? Are there alternative approaches?

Answer 1

Called method signature (generally) doesn't matter as long as you call external, untrusted method without any security precautions.

You should revoke as many SecurityPermissions as possible to minimize attack surface exposed by calling untrusted code from GAC/trusted code. Take a look at this tutorial to get a general idea how .NET Security works. The following should take care of any disruptive behavior external code could cause:

NamedPermissionSet ps = new NamedPermissionSet("Nothing");
ps.Deny();
CallYourUnsafeMethodHere();
CodeAccessPermission.RevertAll();