"Standard I/O only" privileges under Windows - c++

I would like to setup an online judge (automated testing software; takes potentially malicious code and runs a couple of tests on it) on Windows, but such software is usually written for *nix systems, because it's much easier to sandbox code there. Currently it looks like I'll have to write it myself.
How to compile C++ code in a way to prevent any behaviour except stdin/stdout?
How to run an executable in an environment, which allows it to do stdio only?
I've considered deleting some .lib and header files from Visual Studio standard setup, but I'm afraid it's still techincally possible to execute WinAPI calls.
Also, I could create one more OS user, set some rights in Administration control panel, and runas executables from this user to obtain a "secure" environment, but I'm no good in administration, and don't know if it's possible to give the program stdio rights only.

Since this sort of problem will be the target of some rather "bad" code in all sorts of different aspects, I would suggest that ONE possible solution is to use a virtual machine to run the "foreign" code. So, rather than building your server software that does stuff on the real hardware (and potentially messes up or takes over the machine for malicious purposes), you run the code on a virtual machine that has limited resources and strict rules. Once the "result" is complete, you shut down that VM, and start over with a "fresh" VM (created by cloning an previously constructed VM).
And yes, deleting lib's and headers certainly won't stop someone from using calls/functions you don't want to be used. It will make it a tiny bit harder, but only a tiny bit. Most of the "harmful" calls are in the system win32.dll that you also need for system I/O and such things.

Related

keeping DLL on local computer secret, despite sharing with other programs on local computer

I've seen lots of discussion on this forum about keeping code secret, mainly in terms of preventing reverse engineering and decompiling. The typical answer is something along the lines of reverse engineering is always possible, and only thing 100% secure is not distributing your code.
I wrote a c++ function and compiled into a DLL that will only be kept on my computer. However, it needs to be used by an executable on my computer that (1) I didn't write, and (2) needs an internet connection. Is there anything I can do to ensure that the executable doesn't "reveal" the inner-workings my function to anyone at a remove location?
Your computer could be hacked, either by the one program using your DLL or by any other software you're using, and once hacked the DLL can be collected if it's of any interest to the attacker.
The software using your DLL may have the capability to upload the DLL, either directly or indirectly (such as by reporting crashes and logs)
If this DLL is manually injected into the program (or does anything else that may seem suspicious), it may be identified as a cheating/hacking tool either by part of the program or by things such as third party AVs (which occasionally love uploading files to their backend).
The three scenarios are not all that plausible, and unless this DLL contains a real secret or you have a real adversary interested in the content of your DLL i'd say you don't need to worry too much.

Is it possible to directly run C++ at assembly level?

Recently I have been learning how to program in C++, and was wandering, if compiler languages are translated to machine code is it possible to just simply run the code as if it was an assembly code? Or in another example I load just the compiled code onto a formatted flash drive and nothing else and plug up that flash drive into a computer with no OS on it what so ever, and boot from the flash drive to make the computer run the compiled code, and nothing else. Is something like this even possible? Is the language not supported directly by the processor or is some sort of interpreter/execution environment for the language needed to run the program?
Sorry if what im asking is a bit abstract, tbh I don't know exactly how to explain it beyond providing examples.
Almost.
You will probably need some initialization before you can hand execution over to compiled C++. For example you would maybe need to initialize the stack pointer and other low level initialization that can't be done in C++.
After that you should be aware that there are some initialization that needs to be done before main is being run, but that could normally be done in C++, especially if you want a reasonable set of the features of the language (memory allocation, exception handling etc) available.
You should also be aware that much of the functionality that are taken for granted are normally handled by the operating system. Without an OS the executable would have to have libraries that handles that functionality if needed (like for example stream output functionality, file system etc).

How to Prevent I/O Access in C++ or Native Compiled Code

I know this may be impossible but I really hope there's a way to pull it off. Please tell me if there's any way.
I want to write a sandbox application in C++ and allow other developers to write native plugins that can be loaded right into the application on the fly. I'd probably want to do this via DLLs on Windows, but I also want to support Linux and hopefully Mac.
My issue is that I want to be able to prevent the plugins from doing I/O access on their own. I want to require them to use my wrapped routines so that I can ensure none of the plugins write malicious code that starts harming the user's files on disk or doing things undesireable on the network.
My best guess on how to pull off something like this would be to include a compiler with the application and require the source code for the plugins to be distributed and compiled right on the end-user platform. Then I'd need an code scanner that could search the plugin uncompiled code for signatures that would show up in I/O operations for hard disk or network or other storage media.
My understanding is that the STD libaries like fstream wrap platform-specific functions so I would think that simply scanning all the code that will be compiled for platform-specific functions would let me accomplish the task. Because ultimately, any C native code can't do any I/O unless it talks to the OS using one of the OS's provided methods, right??
If my line of thinking is correct on this, does anyone have a book or resource recommendation on where I could find the nuts and bolts of this stuff for Windows, Linux, and Mac?
If my line of thinking is incorrect and its impossible for me to really prevent native code (compiled or uncompiled) from doing I/O operations on its own, please tell me so I don't create an application that I think is secure but really isn't.
In an absolutely ideal world, I don't want to require the plugins to distribute uncompiled code. I'd like to allow the developers to compile and keep their code to themselves. Perhaps I could scan the binaries for signatures that pertain to I/O access????
Sandboxing a program executing code is certainly harder than merely scanning the code for specific accesses! For example, the program could synthesize assembler statements doing system calls.
The original approach on UNIXes is to chroot() the program but I think there are problems with that approach, too. Another approach is a secured environment like selinux, possible combined with chroot(). The modern approach used to do things like that seems to run the program in a virtual machine: upon start of the program fire up a suitable snapshot of a VM. Upon termination just rewind to tbe snaphot. That merely requires that the allowed accesses are somehow channeled somewhere.
Even a VM doesn't block I/O. It can block network traffic very easily though.
If you want to make sure the plugin doesn't do I/O you can scan it's DLL for all it's import functions and run the function list against a blacklist of I/O functions.
Windows has the dumpbin util and Linux has nm. Both can be run via a system() function call and the output of the tools be directed to files.
Of course, you can write your own analyzer but it's much harder.
User code can't do I/O on it's own. Only the kernel. If youre worried about the plugin gaining ring0/kernel privileges than you need to scan the ASM of the DLL for I/O instructions.

Point Cloud Library's multiple-inheritance with single inheritance restriction

The C++ plugin API in which I work is bad enough without STL/exception handling but it also forbids multiple-inheritance. In other words, I can build with it if I don't mind my plugin crashing the host application on startup or I can go single and it will crash on the first direct instance of multiple inheritance in PCL (of which there is only one instance in my plugin code, but that is all it takes one supposes, and, yes, it is a required instance).
I assume that any multiple inheritances used within the PCL libs are isolated (since they appear to use this feature often) but as soon as I use something with it directly - crash.
There seem to be very few options. I can try to find another library for point cloud surface meshing with commercial usage licensing (ha!) or actually write a separate executable using PCL that is called from the plugin to do the work and pass the results back to the plugin (horrendous, platform dependent, and not an integrated solution). This entire entreprise is becoming loathsome. So much time and effort expended researching, preparing, learning, adjusting projects, carefully setting this up only to find that it won't work under these conditions.
If you have an alternative BSD library option to mention that would be great. If you think that I should go for a CL/DOS-based application to be launched to do the processing that would be great to hear arguments for as well. I support both Windows and MacOS X.
Going the external executable route. I can save the point cloud to the pcd format from the application, run the executable to load and process the file to output the results in obj format for the application to use. It is still a horrid solution but at least it works.

Disabling system calls in C++

Is it possible to disable system calls when compiling C++ code? And if it is, how would I do that?
And to extend this question a bit. I wish to make program to not be able to interact with operating system, except for file reading and writing. Is it possible to do this?
EDIT: With not be able to interact with OS, I mean to not be able to change anything in OS, like creating, editing or deleting something. My main concern is system calls, which would almost in all cases be intended to be harmful.
This is for grading programs, where I would be running other people code. The programs would usually solve various algorithmic problems, so there is no need for very advanced features. Basic (more or less) STL usage and classic code. There would be no external libraries (like Boost or anything like that) or multiple files.
Yes, it's certainly possible.
Take a look at the source code for geordi to see how it does it. Geordi is an IRC bot that compiles, links and runs C++ code under an environment where most system calls are disabled.
#define system NO_SYSTEM_CALL
If you are ok with macros to generate errors for compilation purpose.
You could use any combination of the following:
create your own library with a dummy function called system and link it with the student code (assuming you control the build steps)
grep the source code (though preprocessing hacks could get around that)
run the built binaries under an unprivileged user id, after chroot etc.
use a virtual machine
invoke the compiler with -Dsystem= (though the student could #undef)
(maybe - have to check the end-user agreement) upload their source to ideone or similar and let their security handle such issues
An program can always invoke system calls, at leased under *nix it can. You could however take a look at SELinux, Apparmor, GRsec this are kernel safeguards which can block certain system calls for an application.