7

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.

Alex Turpin
  • 46,743
  • 23
  • 113
  • 145

4 Answers4

4

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.

Mark H
  • 13,797
  • 4
  • 31
  • 45
  • +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). – StriplingWarrior Mar 01 '11 at 23:56
  • Wouldn't this require the client to have silverlight installed? – DotnetDude Mar 02 '11 at 15:42
  • @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). – Mark H Mar 03 '11 at 08:35
  • What are your thoughts on using CodeDOM http://msdn.microsoft.com/en-us/library/y2k85ax6.aspx over the Mono DLL? – DotnetDude Mar 03 '11 at 17:21
1

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

StriplingWarrior
  • 151,543
  • 27
  • 246
  • 315
  • 1
    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. – Mark H Mar 01 '11 at 23:52
1

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

ren
  • 3,843
  • 9
  • 50
  • 95
1

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

Shimmy Weitzhandler
  • 101,809
  • 122
  • 424
  • 632