Identifying and preventing execution of "any" function via Late-Bound commands

Question

The Command Pattern is widely used to create a robust, salable applications. However I see guidance in this MSDN article that could allow a caller to invoke a late-bound command... enabling the caller to call any assembly, class, and method available to the running process:

Figure 7

[Serializable()]
public class LateBoundCommand : ICommand
{
    protected string AssemblyName;
    protected string ClassName;
    protected string MethodName;
    protected object[] Parameters;

    protected LateBoundCommand()
    {
    }

    public LateBoundCommand(string assemblyName, string className, 
                            string methodName)
    {    
        AssemblyName = assemblyName;
        ClassName = className;
        MethodName = methodName;
    }

    // sets all parameter values
    public void SetParameters(params object[] myParameters)
    {
        Parameters = myParameters;
    }

    public virtual void Execute()
    {
        Console.WriteLine("LateBoundCommand.Execute starting");
        Assembly a = Assembly.LoadWithPartialName(AssemblyName);
        Type TargetType = a.GetType(ClassName);
        MethodInfo TargetMethod = TargetType.GetMethod(MethodName);
        TargetMethod.Invoke(null, Parameters);
        Console.WriteLine("LateBoundCommand.Execute complete");
    }

}

Since this article was published in 2004, and the underlying pattern was developed in 1995, there must be a lot of software developed this way. Outside of SDLC what is the right way to protect IT Infrastructure from software developed this way?

Is there any .NET or Java specific auditing that can be done to identify late bound execution... atypical of the running service?

Can I scan the MSIL (or Java equivalent) for this type of invocation?

Answer 1

Sure, you could scan the MSIL for code that calls into the reflection bits, but there really isn't much that can be done at runtime unless you are monitoring the call stack on each request.

Answer 2

This is actually just one of very many ways to open the door to invocation of "unexpected" code. Static analysis tools like FxCop or NDepend can help find some potential problems, as can penetration testing tools, but definitely not all of them. Restricting the runtime permissions of the code can help but, unless you're running a programme like SDL, you'll probably end up in a tug-of-war with developers wrt to the runtime permission grant. And even this isn't nearly enough unless security within an application is reasonably robust, which it presumably wouldn't be in an application that contains code like your sample.

Ultimately, if you care about security, you need to put some serious effort into implementing it at all stages of development and deployment. Anything less will be equivalent to spot-checks that leave the door open to problems that might otherwise have been prevented.

Answer 3

The question seems to assume that late-bound invocation of methods is a security problem. However, I don't think it's obvious that this is in fact the case. Generally speaking, most use of late-bound invocation (also known as reflection) is routine and benign.

The question doesn't define the threat model that you are trying to defend against. If you are worried about malicious code injection attacks, then I don't see why late-bound invocation is relevant. Once the attacker can inject and cause execution of malicious code of his choice, the game is over -- and this is true regardless of whether the platform supports late-bound invocation of methods or not.

Consequently, it's not clear to me that there is much value in scanning for code that uses late-bound invocation (aka reflection).

Now, with that said, there are indeed some kinds of security bugs that can arise from incautious use of late-bound invocation of methods / reflection. See, e.g., Fortify's explanation of unsafe reflection and OWASP's article on reflection injection. If your company is developing security-critical code and makes non-trivial use of reflection, you might want to ensure that your developers are aware of these vulnerabilities so they can avoid them. These vulnerabilities are easy to avoid, and I would imagine that they should be rare if developers are following good security practices. However, if you are concerned, a good security static analysis tool should be able to catch many of these sorts of reflection-related vulnerabilities.

At least for Java, another danger of reflection is that Java reflection can bypass Java access control modifiers. For instance, it can enable you to read and write private fields on other classes, something that normally you wouldn't be able to do. If you were relying upon these fields to be truly private, then this might pose some risks to your system. See, e.g., What is the security risk of object reflection?. These comments relate to Java reflection, however, I have the impression that similar concerns may apply to .NET as well. This is not a direct security concern for most systems, but it does make it harder to reason about your code (because it violates encapsulation), which may not be desirable if the code is security-critical.