Online c# interpreter security issues

Question

I am toying around with the idea of building an online C# interpreter, a bit like Codepad. Now there are obvious security issues:

• Infinite loops
• System.Diagnostics.Process.Start
• Pretty much the whole System.IO namespace

My knowledge of C# isn't exactly insignificant, but I'm sure there are a lot that know much more about it, plus the stuff I didn't think about. What would you be careful about?

A few precisions, I plan on running this on a small Linux VPS using Mono.

Answer 1

Use Mono's Compiler as service capability. It can be compiled to a Silverlight compatible DLL (client profile), and has been already, which you can checkout. That should address some of your concerns about IO.

Answer 2

Reflection comes to mind, since you could go from GetType() to Assembly to just about anything you want.

Answer 3

Check out this link, and you will be able to learn somethings on online C# interpreters, try out some things and read the output exceptions to see how they made it.

http://rextester.com/NWDF62346

Answer 4

Actually user code can do anything. it would be hard to tackle special cases. In my opinion the best way to go is:

a) create sandbox appdomain with execution permission only. This ensures a lot of things like inability to mess with file system or make calls to native libraries.

b) create new process and start your appdomain in it.

Then monitor process tightly for memory and cpu consumption. If anything goes wrong - kill it. Note that it's the process you can kill, not appdomain. With appdomain you can try to unload it, but if malicious code running in finally clause then it wouldn't work.

There are still some (known to me) issues with this:

• Be careful where you place user compiled assemblies. Actually even in least privileged appdomain user code will be able to load assemblies that are in the same directory and execute them.
• I mentioned you should monitor process tightly. Code (running in finally clause) which spawns threads in infinite loop, where each thread does the same grabs memory extremely fast (at my observations). if an attacker decides to make dos attack with such code - who knows what happens:) Perhaps one way to leverage this is to start user process with low priority so that supervising threads have a chance of proper monitoring in a loaded system.

So all in all there is a risk anyway. i was toying around with this idea too and here is the current result: rundotnet