2

So, I am making a online application that user's can submit code and the output will be shown to the user. I have made Security a top priority and have taken the following steps to make sure that the code runs securely:

  • Running the code on a VM, On a VPS that's only use is to run these VM's. These VM's do not allow any networking or file access past the working directory.

  • Using the following G++ flags:

    -O -std=c++98 -pedantic-errors -Wfatal-errors -Werror -Wall -Wextra -Wno-missing-field-initializers -Wwrite-strings -Wno-deprecated -Wno-unused -Wno-non-virtual-dtor -Wno-variadic-macros -fmessage-length=0 -ftemplate-depth-128 -fno-merge-constants -fno-nonansi-builtins -fno-gnu-keywords -fno-elide-constructors -fstrict-aliasing -fstack-protector-all -Winvalid-pch

My Question I guess is really how can I make this any more secure? Do you personally see any problems with this approach?

Seki
  • 11,135
  • 7
  • 46
  • 70
Cody Butz
  • 294
  • 4
  • 15
  • 1
    There's really no point in preventing C++03. C++0x *maybe* as it's Standard library includes threads, but there's nothing wrong with C++03. – Puppy Jan 26 '11 at 22:25

4 Answers4

9

The compiler flags don't really matter. A C++ program with those flags can do the same things as a C++ program compiled with any other set of flags. In particular, there are dozens of ways to pull off undefined behavior and yes, potentially exploiting any security vulnerabilities that may exist in the OS.

You're executing untrusted code, end of story. You can hope that the OS won't be compromised, that the code won't be able to gain new permissions or even run as root, or otherwise mess up the system.

And you can hope that if that happens, it'll still be contained within the VM and won't be able to affect the host.

But it's still untrusted code, and it can do anything that untrusted code might be able to do. The best you can do is make sure that it runs with a minimum of privileges, and that the OS and virtualization software are both 100% patched up.

Of course, with the restrictions you mention, my first question is, "is there anything to stop me from filling the harddrive with junk?" Ok, so I can't write outside the working directory, but I can still make the disk run out of space. Or is there a disk quota or anything enforced? How about limiting the amount of CPU time I use? Will I be able to use all the resources on the machine, making it nonresponsive?

jalf
  • 243,077
  • 51
  • 345
  • 550
  • The only correct answer. Surprisingly, this concept seems to be lost on loads of people who report security problems. [It's not surprising that you can run code](http://blogs.msdn.com/b/oldnewthing/archive/2010/12/08/10101773.aspx) ;) – Billy ONeal Jan 26 '11 at 22:32
  • more generally, I think that besides exploits, any form of Denial of Service should be considered. This also includes memory by the way :) – Matthieu M. Jan 27 '11 at 07:33
0

If you are using Linux to run the code you could improve the security of your VM's by redefining some potentially dangerous functions like: open(...), fopen(...), socket(...), and so on using LD_PRELOAD.

Elalfer
  • 5,312
  • 20
  • 25
  • 1
    Problem is that there's always the chance you missed one of the so-called potentially dangerous functions. – Billy ONeal Jan 26 '11 at 22:30
  • Yes, it is possible. But I said that it will just improve security, not make it total secured. And he will be able to monitor if anybody will try to use defined functions and block accounts. – Elalfer Jan 26 '11 at 22:33
  • This is an example of a technique called "defense in depth". It's intended to limit the damage, and should always be combined with methods to prevent damage. Using a throwaway VM is such a prevention (its loss is expected, not damage) – MSalters Jan 27 '11 at 11:57
0

AnYou can use user-level security. You're running native code, which means your code may do anything that the user may do. So, limit what the user may do. Add the "no network, no file access outside working directory" limitation to the users' restriction too. You'd still keep the VM rule, of course, but you'd prefer to catch those things early.

Since you mention GNU, I'll assume a linux system. You'd then want a SELinux VM. Anything you add to the VM could be compromised, so skip it. There's probably no need to have an X server installed, etcetera.

MSalters
  • 173,980
  • 10
  • 155
  • 350
-1

Take a look at http://code.google.com/p/nativeclient/

SK-logic
  • 9,605
  • 1
  • 23
  • 35