Omer van Kloeten's .NET Zen

Programming is life, the rest is mere details

News

Omer van Kloeten's Facebook profile

Get Firefox

.NET Resources

Articles :: CodeDom

Articles :: nGineer

Culture

Projects

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.

Posted: Apr 14 2007, 02:52 PM by Omer van Kloeten | with 10 comment(s)
Filed under: , , ,

Comments

Wilco Bauwer said:

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:

[code=C#]

class Foo {

   void Format(object o) { good }

}

...

  static void Format(this Foo f, string x) { bad }

...

Foo f = new Foo();

f.Format("hello");

[/code]

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).

# April 14, 2007 4:36 PM

Omer van Kloeten said:

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.

# April 14, 2007 5:12 PM

Phil Winstanley said:

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.

# April 14, 2007 5:24 PM

Wilco Bauwer said:

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.

# April 14, 2007 5:44 PM

Omer van Kloeten said:

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?

# April 14, 2007 6:02 PM

Daniel Moth said:

>> 

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.
# May 17, 2007 6:19 AM

Daniel Moth said:

Please either publish my whole comment (that addresses your comment in chevrons) or remove it - otherwise it makes no sense.
# May 17, 2007 1:30 PM

Omer van Kloeten said:

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. :)

# May 17, 2007 5:30 PM

Daniel Moth said:

Click on my name to see see my blog post. Points 2, 3 and 4 answer your questions :)
# May 17, 2007 6:05 PM

Name of the blog said:

More things to consider about the new C# feature, Extension Methods

# September 1, 2007 12:09 PM
Leave a Comment

(required) 

(required) 

(optional)

(required)