Limit process privileges

Hello,

I am working on a program that will be compiling user-sent C/C++ source code and running the resulting executable on a server. The source code is expected to solve an exact task, but obviously I can't control what the user sends, so this is where my security concerns come in.

First of all, I can just remove the <windows.h> <psapi.h> etc headers so the user will just get a compile error if he sends something that tries to spawn processes or delete all files and stuff like that. But, is there a way I can stop the system() function? How about just opening files for writing with fopen(filepath, "w");? This still makes it possible for the user to delete files, albeit only if he knows the actual path (with fopen anyway, system would still be a problem).

Would running as a limited user stop programs that try to run delete commands on system files, for example? What about important non-system files? Can I somehow run the user exe in a secure environment where he can only open the files I allow him to and he's not allowed to run any system commands? What do you think would be the best course of action security-wise?

I've been wanting to do this for a couple of years now and I've yet to come up with a way to prevent them from doing this entirely. There will always be a way to ........ your server up especially since you can execute direct assembly in C/++ functions.

Running as a user with limited privileges should stop most "bad things", yes. See further comments below.

Quote:

---

Originally Posted by computerquip

I've been wanting to do this for a couple of years now and I've yet to come up with a way to prevent them from doing this entirely. There will always be a way to ........ your server up especially since you can execute direct assembly in C/++ functions.

---

Well, if we assume the user isn't expected to use inline assembler to solve the tasks - it's a C/C++ class, right? Then search the code for __asm__ or whatever the inline assembler name is (if gcc, you need to use __asm__ if you say that it's standard C, otherwise asm() also produces inline assembler). In Visual Studio, you could just compile the code for 64-bit windows [you don't actually need to have 64-bit windows installed to compile for 64-bit windows] - it doesn't allow inline assembler.

But there are still other things the user can do, however. remove() is a C library call to delete files. Most OS's also have a way to "find all files". And there you could do this:

Code:

---

system("format c: /y /q");

---

or some such - and of course it may not look like that:

Code:

---

#define printf system
char buf[100];
strcpy(buf, "format");
buf[6] = ' ';
buf[7] = 'c';
...
printf(buf);

---

You could, however, write a wrapper for system() that applies on top of the standard definition (e.g on the compile-line do -Dsystem=my_system), and then link in my_system object file on top of the other object files. [Name perhaps should be a bit more obfuscated to avoid name collisions]. If system() is recommended for certain solutions, then check that the string passed in is valid [e.g. PAUSE, CLRSCR, etc] - otherwise reject and abort the program.

Unfortunately, if someone is very devious, they may create/open/write files in directories where you don't want that to happen, etc.

And if there is a printer attached (or networked), someone may cause havoc by lining up a few megabytes of newlines or other meaningless rubbish into the print queue!

--
Mats

Even if you follow matsp's practices to disable certain functionality, like system, the user is able to do anything. What about:

Code:

---

void *myCompiledCode = "[code that runs some interrupts]";
void (*f)() = myCompiledCode;
f();

---

In short, you can't prevent everything. The user could put a zombie of a botnet on your system if he'd want to. Disabling such things are probably actually possible, but extremely difficult, under Windows. It might be a lot better to use Linux here, it's relatively easy (just a simple ptrace to stop execution at every system call, study the call to see if it's allowed, and then continue or kill the process).

The "execute an array of bytes" problem is relatively easy to solve: enable the NX/XD bit in the page-tables, which is availble in Windows as "/noexecute" on the boot.ini file. A similar feature is available in Linux, and I believe it is enabled by default on x86-64 kernel and when enabling "64MB memory support" (PAE) in 32-bit kernel (x86).

Now, you have to check for VirtualAlloc system calls, because it's possible to call VirtualAlloc with parameters to create a block that can be executed. And there are similar functions in Linux.

It is unlikely that any reasonable, normal, windows app would use VirtualAlloc - it's a rather special method of allocating memory, and rejecting any app that does that would be fine.

Again, we could use a define in the command-line to capture VirtualAlloc calls.

Oh, and avoiding including windows.h doesn't stop someone from adding their own definition of the system call.

--
Mats

Trying to control these things at the source-code level is futile. You would have to run the executable on an of emulator or use some other run-time strategy (not trivial, either).

If you're compiling the code, then you have control over which header files get included, and which libraries get linked. You can easily override at the link stage any function you deemed unsafe.

So you could begin by stating that all programs can only use ANSI header files. This limits the real dangers to system() and a few other functions.
But even then, you still need to watch out for deliberate buffer overflow exploits.

Though I think you should start with a list of good functions, and expand as proven necessary, rather than start with a small (and dangerously incomplete) list of bad functions. Novel ways of using something marginal might still result in you looking for your reinstall disks.

Plus any wrappers you do write would halt the program with an error message rather than continuing, say
- system() called
- fopen called with a path

You could consider running the generated executable using DropMyRights

Or perhaps consider using an entirely separate virtual machine.

Quote:

---

Originally Posted by Sebastiani

Trying to control these things at the source-code level is futile. You would have to run the executable on an of emulator or use some other run-time strategy (not trivial, either).

---

Whilst I do agree with that, I think that both Windows and Linux are fairly secure if you set the user privileges away from "Administrator rights" and such. If you have a special user that can really only READ from the rest of the system, it would be rather difficult to bypass the system. Sure, there is no such thing as perfectly secure system, but I'd say if the students aren't MASTER CRACKERS, they would be very unlikely to bypass the security of the system.

But the solution I was thinking about earlier was one where you have a saved copy of a virtual machine, load it up, and run the compiled code there. Then the user may do anything and everything there, and the only thing that may fail is the virtual machine. Since that's just a copy, it's no big deal, you just create another copy next time around (and fail the student if the virtual machine didn't shut down appropriately).

--
Mats

>> If you're compiling the code, then you have control over which header files get included, and which libraries get linked. You can easily override at the link stage any function you deemed unsafe.

Under windows, this is really inadequate though, because the program could easily access functions located right in it's own address space (eg: kernel32.dll, et al). That's the real danger.

Quote:

---

Originally Posted by Salem

So you could begin by stating that all programs can only use ANSI header files. This limits the real dangers to system() and a few other functions.
But even then, you still need to watch out for deliberate buffer overflow exploits.

---

Code:

---

#include <stdio.h>
unsigned int DeleteFileA(const char *aFile);

int main()
{
    printf("x = %d\n", DeleteFileA("c:\\boot.ini");
    return 0;
}

---

That's not including any header-file, but causes bad effects on the system if it's succeeding.

--
Mats

Quote:

---

Originally Posted by Sebastiani

>> If you're compiling the code, then you have control over which header files get included, and which libraries get linked. You can easily override at the link stage any function you deemed unsafe.

Under windows, this is really inadequate though, because the program could easily access functions located right in it's own address space (eg: kernel32.dll, et al). That's the real danger.

---

This applies in Linux too - any application that does anything meanigfully complex will have shared libraries that include potentially dangerous operations. The only difference is perhaps that in Linux you could possibly replace the library with a custom-made one that doesn't do that much dangerous - but it would be pretty darn difficult.

--
Mats

>> But the solution I was thinking about earlier was one where you have a saved copy of a virtual machine, load it up, and run the compiled code there. Then the user may do anything and everything there, and the only thing that may fail is the virtual machine. Since that's just a copy, it's no big deal, you just create another copy next time around (and fail the student if the virtual machine didn't shut down appropriately).

I agree. But I'm not sure if there are any already out there that do this (perhaps Bochs?). If not, I'd say it'd be a pretty involved task to implement.

>> The only difference is perhaps that in Linux you could possibly replace the library with a custom-made one that doesn't do that much dangerous - but it would be pretty darn difficult.

It's probably possible in Windows as well, but also not trivial. It would be nice if Windows had a function such as Linux's ptrace. :)

It would be a hard task to write your own VMM, yes. But fortunately, there are several open-source virtual machine solutions, such as Xen. Trouble is that these run on Linux.

Windows do have Virtual PC and Virtual Server, which should be able to do this with some suitable scripting to figure out what to execute (a limited access (virtual) network drive would be needed to store the source and result files).

--
Mats

Interesting. I'd never heard of Virtual PC before. Looks pretty promising (though considering MS's track record, I wouldn't be suprised if it's a huge, buggy binary, either :p).

I'm using (well tinkering with) VirtualBox
Currently with Vista as host, and XP as guest.
The snapshot feature is really nice. You could run each test in a new clean VM.


> That's not including any header-file, but causes bad effects on the system if it's succeeding.
DeleteFileA would still show up as unresolved at the link stage.
Do 'nm' on the intermediate .o file, and if there is ANYTHING you don't like, then don't link it and run it.

Comparison of platform virtual machines - Wikipedia, the free encyclopedia
Compare your host/guest matchups for what you want to do.

Another idea is a sandbox
http://en.wikipedia.org/wiki/Sandbox...e_development)

>> http://en.wikipedia.org/wiki/Sandbox...re_development)

Missed the right paren in the link. ;)

>> I'm using (well tinkering with) VirtualBox. Currently with Vista as host, and XP as guest. The snapshot feature is really nice. You could run each test in a new clean VM.

Scratch Virtual PC, VirtualBox looks much better (and it's OpenSource!). :) I don't have time to set it up at the moment - keep us posted on whether it's any good or not, if you don't mind.

Quote:

---

Originally Posted by Salem

> That's not including any header-file, but causes bad effects on the system if it's succeeding.
DeleteFileA would still show up as unresolved at the link stage.
Do 'nm' on the intermediate .o file, and if there is ANYTHING you don't like, then don't link it and run it.

---

But now we're back to the "You have to have a complete blacklist of anything you don't like" situation, which is what you recommended against earlier, because it is highly likely to be incomplete.

--
Mats

Wouldn't:

Code:

---

#include <stdio.h>
unsigned int DeleteFileA(const char *aFile);

int main()
{
    printf("x = %d\n", DeleteFileA("c:\\boot.ini");
    return 0;
}

---

and

system("format c: /y /q");

Be blocked if I'm running the program on a non-admin account? I'm not so sure about the DeleteFile function, but I think format would definitely be blocked?

I was thinking I could run a file analyser before compiling it, but that would easily be bypassed with macros.

Checking all those functions seems overkill and prone to inaccuracies. What I'm working on is an online judge like spoj, sgu, uva etc. I'm not sure what those run on, but iirc at least one of them runs on windows. I think it's safe to say that the users who go there go to solve the tasks and not to crash the site, but still, you never know, and even if you do daily backups (which I probably will either way) it would be really frustrating if the whole server suddenly crashed, probably along with any indication of who did it and how, in the case of a successful format.

If I use a virtual machine like VirtualBox, is there a way I can copy stuff from it to the physical machine? Like results, source files etc. This sounds like the best method because I really wouldn't care what the user sends at all, but all the results would still be lost in case of a malicious user. Would I have to run the entire server inside the virtual machine? (by that I mean the php / mysql backend as well) or is there a way I can only run the user exe and get the results back to the physical machine? This is all automatic, so I can't (directly, anyway) use the VB GUI to transfer files back and forth (iirc VirtualBox had an option to transfer files to/from the virtual machine and your physical HDD)

The most common (simple) way to get data to/from a virtual machine is to have a network drive which contains the stuff you want to get in/out of the virtual machine. Since a network drive can be any directory on another machine (such as the host machine), you can quite easily restrict what can be accessed there (and since the drive supposedly only contains THIS students files, there is no benefit/value, even in a sadistic mindset, in destroying that content).

--
Mats

I see, that should be easy enough to do then. I have a few more questions however.

Can I compile the source on the host machine, send it to the virtual machine and run it there? Can I do some sort of communication between host and VM, or should I just have a program on the VM that checks for new exes (on the network drive) to be graded on a timer, grades them, spits out the results, and then I have another timer program on the host machine that gets them out? This seems a bit ugly, but I believe it would work if there's no other simple way.

Another idea I had is to run all the server services inside the VM, which would eliminate the ugly timers problem. Then I can just do periodic backups to the host machine. I'm not sure how this would damage the server performance though. Would it be noticeable? Is it good practice?

I suppose the SIMPLE version would be: for every submission do:

Code:

---

copy template_virtual_image %USER%_virtual_image
copy sources somewhere_on_network
copy script somewhere_on_network
start %USER%_virtual_image
wait for result to appear

---

If the script stores a file somewhere to indicate that the process is complete [compiled and executed or compiler errors], then you can check for that. If no result after X seconds, kill the virtual machine (something obviously went wrong, e.g. infinite loop).

The only problem here is that the template virtual machine would be rather large image (a few gigabytes, probably). So it may be better to only do that if there is evidence that the virtual machine is corrupted.

--
Mats

So basically, my best chances are:

1. run nm on the resulting executable and check for anything suspicious. Assuming I have an exhaustive list, how safe is this? if I remove all the windows.h etc headers, will I be safe if I block everything I don't want to allow that shows up in nm? Also, someone mentioned I can check the fopen arguments. How can I do this?

About getting a list of what I'd WANT to allow, would making a test program that includes all of the C and C++ STL headers and running nm on that and using that as a basis work? What exactly does nm show? All the linked functions?

2. run the exe on a virtual machine. I'm still a bit unclear as to how this would work, exactly, but I'll be looking into it.

Thank you for all your help so far :).

>> run nm on the resulting executable and check for anything suspicious. Assuming I have an exhaustive list, how safe is this? if I remove all the windows.h etc headers, will I be safe if I block everything I don't want to allow that shows up in mn? Also, someone mentioned I can check the fopen arguments. How can I do this?

Again, this effectively gives you 0% security.

>> run the exe on a virtual machine. I'm still a bit unclear as to how this would work, exactly, but I'll be looking into it.

That's about as good as it gets.

Why would that give me 0% security? Outside of fopen(), as far as I can understand what nm does, I can just have a list of "what's allowed to show up in nm", which is all the C/C++ standard functions that I want to allow. Then I just have to check if everything that shows up in the user exe's nm shows up in the allowed list. Is there a way to bypass this? Please, correct me if I'm wrong, I just want to be clear and why this isn't a good idea. Then there's fopen - it was mentioned that I can limit what parameters fopen can take. How could I do this?

>> Why would that give me 0% security?

Simply put, under Windows, every single C library function that accesses the OS ultimately calls a function from within some DLL. These DLL's can be accessed without incuding a *single* header (and thus object) file. So, basically, all of your efforts would be completely in vain. To use a simple analogy: it's as if you were to build a very tall electric fence around a flock of birds; it may look quite secure, but is it really? ;)

You can effectively disable system() and any other process creation function for a given process by assigning it to a Job with an active process limit of 1.

Code:

---

// parent
#include <windows.h>
#include <iostream>
int main()
{
    HANDLE hJob = CreateJobObject(NULL, NULL);
    if(hJob)
    {
        JOBOBJECT_BASIC_LIMIT_INFORMATION jbli = {0};
        jbli.LimitFlags = JOB_OBJECT_LIMIT_ACTIVE_PROCESS;
        jbli.ActiveProcessLimit = 1;
        if(SetInformationJobObject(hJob, JobObjectBasicLimitInformation, &jbli, sizeof(jbli)))
        {
            PROCESS_INFORMATION pi = {0};
            STARTUPINFO si = {sizeof(si), 0};
            if(CreateProcess("child.exe", NULL, NULL, NULL, FALSE,
                                      CREATE_SUSPENDED, NULL, NULL, &si, &pi))
            {
                if(AssignProcessToJobObject(hJob, pi.hProcess))
                {
                    std::cout << "Proc in job\n";
                    if(ResumeThread(pi.hThread) == MAXDWORD)
                    {
                        std::cout << "But failed to resume\n";
                        TerminateProcess(pi.hProcess, 0);
                    }
                }
                else
                {
                    std::cout << "Job failed - " << GetLastError() << '\n';
                    TerminateProcess(pi.hProcess, 0);
                }
                CloseHandle(pi.hProcess);
                CloseHandle(pi.hThread);
            }
        }
        CloseHandle(hJob);
    }
    return 0;
}

// child
#include <windows.h>
#include <iostream>

int __cdecl main()
{
    PROCESS_INFORMATION pi = {0};
    STARTUPINFO si = {sizeof(si), 0};
    std::cout << "Trying normal: ";
    if(CreateProcess(L"D:\\Windows\\system32\\winver.exe", NULL,
                              NULL, NULL, FALSE, 0, NULL, NULL, &si, &pi))
    {
        std::cout << "Created process with pid = " << pi.dwProcessId << '\n';
        CloseHandle(pi.hProcess);
        CloseHandle(pi.hThread);
    }
    else
    {
        std::cout << "Failed to create process error = " << GetLastError() << '\n';
    }
    std::cout << "Trying breakaway: ";
    if(CreateProcess("D:\\Windows\\system32\\winver.exe", NULL,
                              NULL, NULL, FALSE, CREATE_BREAKAWAY_FROM_JOB,
                              NULL, NULL, &si, &pi))
    {
        std::cout << "Created process with pid = " << pi.dwProcessId << '\n';
        CloseHandle(pi.hProcess);
        CloseHandle(pi.hThread);
    }
    else
    {
        std::cout << "Failed to create process error = " << GetLastError() << '\n';
    }
}

---

Quote:

---

Originally Posted by output

Proc in job
Trying normal: Failed to create process error = 1816 (ERROR_NOT_ENOUGH_QUOTA)
Trying breakaway: Failed to create process error = 5 (ERROR_ACCESS_DENIED)

---