Extension Methods and Trust

As much as I love the idea behind extension methods, I can’t help but start to think about how it could be used for malicious purposes.

Take this scenario:

  1. You’re a disgruntled employee of Evil Inc., the makers of the well known library VeryUsefulAssemblies.NET.
  2. I’m a developer at Good & co., using your Tree<T> class in an assembly called Evil.UsefulAssembly.
  3. Before quitting your job, you decide to add an extension method, System.String.Format(params object[] args), that sends sensitive information back to you and then calls System.String.Format(string format, params object[] args) so no one notices.
  4. I have now unwillingly compromised all of my clients and could never know it, unless I manually check my IL or use a sniffer.

But wait! There’s more:

  1. A fellow developer in my company, Norman I. Huntington, decides to write his own Tree<T> and replace all of the references to your Tree<T>, but he forgets to remove the reference to your assembly.
  2. Now my application doesn’t even use your assembly, but is still hijacked!

Problem? I think so.


8 thoughts on “Extension Methods and Trust

  1. I see your concern, but I don't think you need to worry.
    1. String.Format is a static method so this doesn't really apply. But sure, let's assume for now it was an instance method.
    2. Method extensions don't use the same rules as general method overloading (or at least I sure hope they don't). This means that if you provide an extension method which would bind BETTER to a certain method call than non-extension methods, it should NOT have any effect. Example:
    <p>class Foo {</p>
    <p> &nbsp; &nbsp;void Format(object o) { good }</p>
    <p> &nbsp; static void Format(this Foo f, string x) { bad }</p>
    <p>Foo f = new Foo();</p>
    In this example the extension method will NOT be used because the actual instance method already matches. If the extension method wasn't an extension method but an actual overload, it WOULD be called (obviously).

  2. Well, you’re right. I’ve looked at the spec again and it does say it searches from inside out.
    However, this doesn’t apply to when two different extension methods exist and the fact that their selection isn’t deterministic.
    Also, since normal overloading rules do not apply, I could create, in your example, an extension method that gets ‘object’ as its parameter and the code would still compile.

  3. In the first example, there’s nothing to stop disgruntled employee just editing the actual method…. I’m not sure extention methods in that case make something more vulnerable to attack.
    In the second example, Norman apparently has access to the source anyway ….
    It’s all about trust, done’ trust something, write it all yourself.

  4. Sure, it doesn’t apply when you are strictly dealing with extension methods. I’m not sure what could be done against that, except for perhaps giving warnings when multiple extension methods could bind, even if one binds better than the other.
    Why would it matter if you would change the extension method’s parameter’s type to object in my example? Sure, it would probably still compile, but it still wouldn’t be called.

  5. Phil –
    * The original method is the one that’s ‘trusted’. The disgruntled employee adds an ‘untrusted’ method to that trusted type, maliciously diverting calls to the ‘untrusted’ method.
    * NIH isn’t a malicious developer. He just forgot a reference and doesn’t suspect anything.
    I trust Evil Inc. and as far as my code shows, it’s not ‘their’ code that’s malicious.
    Wilco –
    The fact that the selection isn’t deterministic is kind of a problem for a language that’s supposed to remain staticly-typed.
    Here’s another scenario I can think about that the spec doesn’t cover, which again causes ambiguity – which comes first: implicit casts or extension methods?

  6. >> 
    However, this doesn’t apply to when two different
    extension methods exist and the fact that their selection isn’t deterministic.
    << Two different extension methods that are in scope (you do
    remember that they have to be in scope right?) will cause a compiler error.

  7. My apologies, the rest of the comment got eaten up for some reason. I’ve fixed the problem.
    Which scope do you mean?
    In the comments above I referred to things I learned during a conversation with a lead from the VB team a while back and haven’t felt the need to double-check. If the problem I referred to now causes a compiler error, I’m glad. :)

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s