Exploitable C# Functions.

Question

This question is similar to Exploitable PHP Functions.

Tainted data comes from the user, or more specifically an attacker. When a tainted variable reaches a sink function, then you have a vulnerability. For instance a function that executes a sql query is a sink, and GET/POST variables are sources of taint.

What are all of the sink functions in C#? I am looking for functions that introduce a vulnerability or software weakness. I am particularly interested in Remote Code Execution vulnerabilities. Are there whole classes/libraries that contain nasty functionally that a hacker would like to influence? How do people accidentally make dangerous C# code?

Answer 1

Process.Start is the first one to come to mind.

I am sure that WindowsIdentity and much of System.Security can also be used for evil.

Of course, there are SQL injection attacks, but I don't think that's what you mean (though remote execution can occur through SQL Server).

Answer 2

I've seen code where the user could set the name and parameters for a function call in a database. The system would then execute the named function through Reflection without checking anything ...

Answer 3

Using any type of unsafe code can cause problems such as pointers. Microsoft provided a good article about unsafe code here: http://msdn.microsoft.com/en-us/library/aa288474(VS.71).aspx

Answer 4

IMO: The nr 1 exploitable functions, are innocent looking, but very dangerously when used without thought.

In ASP.Net Response.Write or the shortcut:

  <%= searchTermFromUser %>

In ADO.Net:

• The string + operator:
  var sql = "SELECT * FROM table WHERE name = '" + searchTermFromUser + "'"

Answer 5

Aside from the obvious Process.Start() already mentioned, I can see a couple of ways of potential indirect exploitation.

• WinAPI calls via PInvoke to CreateProcess() and whatnot.
• Any sort of dynamic assembly loading mechanism using Assembly.Load() and other such overloads. If a compromised assembly made it to the system and loaded.
• If running in full trust in general.
• With the right permissions, any registry operations could put you at risk.

That's all that comes to mind right now.

Answer 6

Plenty of things in the System.Net, System.XML, System.IO, (anything that takes a URI and/or file path and actually deals with the resource they identify) System.Reflection, System.Security, System.Web, System.Data and System.Threading namespaces can be dangerous, as in they can be used to do bad things that go further than just messing up the current execution. So much that it would be time consuming to try to identify each.

Of course, every method in all third party assemblies will have to assumed to be dangerous until shown otherwise. More time consuming again.

Nor do I think it's a particularly fruitful approach. Producing a checklist of functions only really works with a limited library, or with a large-language where a lot of what would be in a library with a language like C# is in the language itself.

There are some classically dangerous examples like Process.Start() or anything that executes another process directly, but they are balanced by being quite obviously dangerous. Even a relatively foolhardy and incompetent coder may take care when they use that, while leaving data that goes to other methods unsanitised.

That sanitation of data is a more fruitful thing to look at than any list of functions. Is data validated to remove obviously incorrect input (which may be due to an attack, or may simply be a mistake) and is it encoded and escaped in the appropriate way for a given layer (there is too much talk about "dangerous" character sequences, ' never hurt anyone, it's ' not correctly escaped for SQL, that can hurt when it is indeed at a SQL layer - the job required to make sure the data gets in there correctly is the same as that to avoid exploits). Are the layers at which communication with something outside of the code solid. Are URIs constructed using unexamined input, for example - if not you can turn some of the more commonly used System.Net and System.XML methods into holes.

Answer 7

Reflection.Emit and CodeDom

Edit:

Allowing plugins or third party libraries that uses threading can bring your whole application down unless you load those libraries/plugins in a separate appdomain.

Answer 8

Any piece of data you get from the user (or any other external source) and pass to another system or another user is a potential exploit.

If you get a string from the user and display it to another user without using HtmlEncode it's a potential exploit.

If you get a string from the user and use it to construct SQL it's a potential SQL injection.

If you get a string from the user and use it to contract a file name for Process.Start or Assembly.Load it's a remote execution vulnerability

You get the point, the danger comes from using unsanitized data, if you never pass user input to external system without sanitizing it (example: HtmlEncode) or using injection-safe interfaces (example: SQL parameters) you are relatively safe - the minute you forget to sanitize something the most innocent-looking method can become a security vulnerability.

Note: cookies, html headers and anything else that passes over a network is also data from the user, in most cases even data in your database is data from the user.

Answer 9

Anything that uses regular expressions (particularly the RegularExpressionValidator). To see this, run a RegularExpressionValidator with the regex ^(\d+)+$ and give it 30 digits to validate against.

Some posts:

• http://msdn.microsoft.com/en-us/magazine/ff646973.aspx
• http://www.abemiester.com/abemiester/post/RegEx-DOS-attack-Regular-Expressions-Now-you-have-3-problems.aspx

This is called a Regular Expression Denial of Service attack and it can bring a website to it's knees.

Answer 10

Probably half the framework contains very scary functions. I myself think that File.WriteAllText() is very scary since it can overwrite any file the current user has access to.

A different approach to this question would be how you can manage security. The article at http://ondotnet.com/pub/a/dotnet/2003/02/18/permissions.html contains a basic description concerning the .NET security system, with the System.Security.Permissions namespace containing all permissions .NET makes available. You can also take a look at http://msdn.microsoft.com/en-us/library/5ba4k1c5.aspx for more information.

In short, .NET allows you to limit the permissions a process can have, for example denying methods that change data on disk. You can then check these permissions and act on whether the process has them or not.

Answer 11

even a simple string comparison can be an issue.

If an application makes a trust decision based on the results of this String.Compare operation, the result of that decision could be subverted by changing the CurrentCulture

Take a look at the example. Fairly easy to miss