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.

Morissa

I know the nature of the question probably isn't very StackExchange-ish, so I figure I'll accept the most complete answer. – Morissa

Doesn't it have essentially the same security mechanism as Java? – Shackleton

Did you finish your interpreter? – Condolent

@Shimmy sadly no, it went with the rest of my mostly unfinished projects in a dusty corner :) – Morissa

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.

Mccluskey

+1: That sounds like the way to go, since Microsoft has already done the work of defining the security risks within the DLL itself. After that, you just have to focus on misuse issues (e.g. people using your service to do DOS attacks). – Hardie

Wouldn't this require the client to have silverlight installed? – Moses

@DotNetDude: In the Runcs example, silvelight is required - but if you were running the Mono.CSharp DLL on a server, it's only the server that requires .NET to be installed. (The Client profile only requires .NET, not silverlight). – Mccluskey

What are your thoughts on using CodeDOM msdn.microsoft.com/en-us/library/y2k85ax6.aspx over the Mono DLL? – Moses

Answer 2

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

Hardie

IMO, reflection is exactly what you want to avoid, since it allows you to execute (potentially) arbitrary code, rather than a restricted subset which you want to enforce for security purposes. – Mccluskey

Answer 3

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

Pester

Answer 4

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

Condolent