Secure Services on Virtual Machines?

Matt2000 asks: "With the growing number of package updates that cross my inbox for my redhat systems, and with the vast majority being buffer overflows, or overflows of some kind doesn't it strike anyone that there must be a better way? Instead of spending time auditing every piece of software for mechanically preventable bugs, why isn't there a common, audited virtual machine that people can build net facing services on? I would guess that sshd, httpd, and sendmail would be good candidates to start, as they are the most common and the most exploited. And please don't freak out performance junkies, if you run a website that serves 70,000 people a second and need to run native apache, then do so. Just accept that it will be less secure."

Comments

Re:Why do you need a VM?

[Hanashi]

I think the original poster is talking about a whole different level of sandboxing. True, chroot environments keep you from playing with other files outside the jailed environment, but they do nothing to address (for example) your ability to install and run a network sniffer on the target.

A good virtual machine, on the other hand, could let you have this level of security because the hardware is virtualized too. VMWare allows you to assign a number of different types of network interfaces to each VM, and using NAT you can prevent the VM's NIC from seeing traffic to/from any other host.

Also, on a more philosophical level, the deeper your defenses are, the better. It's possible to break out of chroot jails (though it's difficult). It may be even harder to break out of a VM. The jury is still out on this, but it's certainly an unexpected move that would probably throw most crackers for a loop.

Mistaken reasoning

[Tom7]

> Imagine a Java sendmail installation running on a JVM. I may be able to compromise jsendmail, and while this won't give me
> local root, I may be able to use the compromised sendmailer to implement social engineering hacks.

How do you expect to compromise jsendmail? If sendmail were written in java, then the 2 most recent bugs would not have been exploitable. Part of the point is that safe languages like Java are not vulnerable to buffer overflows, double-frees, etc.

> Also, if the VM is designed to run "safe" languages that rely on static type checking for safety (such as java) a
> non-too-impossible attach on the machine it is running to randomly corrupt memory could be used to compromise the underlying
> system. See the recent paper by Appel and Govindavajhala.

This is a total red herring. The situation described in their paper is where the attacker gets to supply the program (and also has the ability to induce memory faults on the target). While I might buy the argument that memory faults happen randomly as well, the attacker surely doesn't get to install his own trojaned jsendmail on my computer. (If he did, he could do a lot more damage anyway!) A C program is equally dangerous on a computer with faulty memory--Appel's paper is irrelevant in this scenario.

> Also, don't forget that all those malformed-request attacks against poorly written PERL CGIs that fail to validate strings
> passed to a subshell: perl runs in a VM, but does no good when the attack slips by the VM to the base hardware.

I'm with you here. perl is "safe" in some sense and is interpreted, but is still susceptible to easy security holes. I think this is mostly due to its interpreted and highly dynamic nature, as well as due to some misfeatures in the language (allowing "|/bin/rm" as a filename, etc.). In my (informed, but not substantiated) opinion, statically-typed compiled languages are not typically susceptible to easy-to-make security holes like these. (For instance, to spawn a process in SML, you give the path to the process, and a list of its arguments -- there is no shell globbing to screw up.) I really think that such languages would go a long long way towards making more secure computing environments, and in fact they don't need to run in a VM (see my other post), giving us the best of both worlds!

Re:There is no need to have a VM for safety

[Twylite]

This is complete bullshit. The Java VM is exactly what makes the language safe. Even if you use Java assembler you can't overflow an array boundary, because the VM knows what an array is, knows its limits, and executes the instruction to set an element of the array on your behalf. Most of the RuntimeExceptions and all of the Errors in Java are thrown directly from the VM, not from code libraries.

This means that you can take an arbitrary, untrusted Java executable and run it, and it will not be subject to traditional buffer overflow vulnerabilities.

With a non-interpreted language like C, you can only get this level of trust if you compile the binary. Even then, you can only fully trust C if there is no use of pointer arithmetic, and all pointers are to data of a defined size. Without this knowledge it is not possible to generate code that can check (for example) array bounds.

For example, char* c = (char*)malloc(1000); cannot be statically checked by the compiler. It is possible to develop a compiler that knows of every mechanism that can be used to allocate memory, and annotate a variable with the memory allocated to it, but there are numerous problems with this approach.

It is certainly quite possible to take any sufficiently constrained language and compile it to native code such that it is not susceptible to buffer overflows. But this is quite different from a language-aware VM (like that of Java) where even a malicious binary cannot cause a buffer overflow.

As for C programmers having to live with the various problems you describe -- there are many techniques for avoiding these problems. It is possible to use garbage collection in C++, and get away from direct memory management. Using sized data instead of arbitrary mallocs, and creating classes to represent arrays allows you to overload operators to behave in a safe fashion. The simplest of attention to initialising variables instead of making assumptions because you can squeeze out an extra instruction cycle addresses many string problems.