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

Why do you need a VM?

[0x0d0a]

You've got chroot. Both sandbox the server from the rest of the system. Chroot is just a lot easier to make performance-efficient.

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.

Re:Why do you need a VM?

[ComputerSlicer23]

Yeah, the only problem is go out to any hacker site, and look for details on how to break out of a chroot jail. Hell just put in "break out chroot" as search terms into google, and 5000+ pages come up. While chroot's nice, it's not the almighty security tool most people believe it is. (I'm not sure that having a VM that runs your software would be). UML might be better, or possibly another VM layer. The problem is, you need your VM to be completely audited for all interactions to make sure nobody can break thru to a layer above it, as soon as they can, game over. I'd rather seem UML get more support then chroot. I think chroot is of very limited utility, where UML seems to have a lot more applications, both interms of security (honeypots and as a jail for specific services) and virtual servers/services. However, chroot is more production ready then UML is, so there you have it.

Kirby

Re:Why do you need a VM?

[0x0d0a]

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.

Well...that's true, if you're running a chroot jail with, say apache running as root. But if you don't have any suid binaries in the jail (apache is running as "httpd" or whatever) and your kernel is secure, it should keep you from putting a sniffer on the thing.

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.

Hmm. I'm not saying VMWare doesn't work, but I've seen the VMWare site more and more lean toward trying to sell VMWare as a corporate solution to security. VMWare was always kind of a solution without a problem , and I have a sort of nasty feeling that VMWare (and VMs) are going to be the new stupidly-oversold-to-corporate-IT-people product, like firewalls were before them.

Re:Why do you need a VM?

[Webmonger]

Yes, something does need to be secure.

But there is functionality to be gained from VM+SUID root. Sendmail needs root to use port 25. It would be useful to create a virtual machine that just ran Sendmail, POP and IMAP. Most email users would only have accounts on that VM. Or it would be useful to have a virtual machine that just ran BIND.

I suppose you can use packet-filtering to remap port 53 and 25 to high ports (say, 8053 and 8025), so you don't have to run Sendmail and Bind as root.

But the other a VM is that you don't have to worry about someone getting a local logon through non-root Sendmail and then using privilege escalation exploits to get root on your whole box. The most they'd get access to would be your mail system.

Anyhow, security isn't black-and-white, and defence-in-depth is a reasonable technique. VM+NOSUID+CHROOT would be a very secure config.

StackGuard

[drdink]

You might want to check out StackGuard:

StackGuard is a compiler that emits programs hardened against "stack smashing" attacks. Stack smashing attacks are the most common form of penetration attack. Programs that have been compiled with StackGuard are largely immune to stack smashing attack. Protection requires no source code changes at all.

Re:StackGuard

[Matt2000]

Could I compile existing software, like sendmail, with this and that would remove buffer overflow style explots? If so that's very interesting, how come the binary RPMs that Redhat and crew aren't already compiled with a tool like this?

red pill

[David_Bloom]

Just hope the client doesn't take the red pill. I'd think a virtual machine would be more vulnerable, as there is potential to trick it to run code "outside the box".

User-mode Linux

[quakeslut]

Is this what you're looking for?

quoted from page:
User-Mode Linux is a safe, secure way of running Linux versions and Linux processes. Run buggy software, experiment with new Linux kernels or distributions, and poke around in the internals of Linux, all without risking your main Linux setup.

User-Mode Linux gives you a virtual machine that may have more hardware and software virtual resources than your actual, physical computer. Disk storage for the virtual machine is entirely contained inside a single file on your physical machine. You can assign your virtual machine only the hardware access you want it to have. With properly limited access, nothing you do on the virtual machine can change or damage your real computer, or its software.

I think there is

[(trb001)]

Isn't Trusted Solaris basically just this? At an OS level, you associate trust levels that permeate throughout your network. Two (or more) people can work on the same box at the same time and view completely different boxes because of their trust level. One trust level can't talk to or look at another's processes without the proper authorization. Like Unix file privs only much, much more controllable.

Actually, trusted computing is a pain in the ass for standard development...we always wound up creating a super user program that can run stuff anything to get around priv issues during development. I can see using a system such as this post beta development or for production, but developing under it is a bitch.

--trb

A VM is only as secure as the OS it's running

[Deagol]

Unless I misunderstand your post, I don't think isolating an application inside a VM will do all that much good. I mean, I can run Apache on Red Hat under a VMWare virtual server. However, it can still be broken into the same as a real machine.

Still, there's some merrit to the idea that having each service isolated in its own VM. At least there's some partitioning, and one "captured" service may not interfere with another. Though I'd argue that you should do this same partitioning by using real hardware.

Here's what I do, and it doesn't require that much more overhead:

At the IP level, I use iptables for a default-deny setup. Nothing gets in or out unless I explicity account for it, logging everything that violates policy and then silently dropping the packet.

At the kernel level, I use the grsecurity patch to shore up generic, known weaknesses (stack smashing, buffer overruns), as well as the various randomizations of PIDs, socket numbers, etc. I tried using StackGuard and libsafe for this kind of stuff, but found them too troublesome (plus, grsecurity addresses most of this stuff).

At the application level, I chroot what I can. I then use tcp_wrappers (for apps that use it) in a default-deny config, plus any ACLs that the application itself manages.

Of course, I try to keep up with gaping security holes in services I run. However, I don't find myself scrambling out of fear that my boxes are in much danger when there is an advisory.

These many layers add up to a pretty secure box, that's functional and no more of a hassle to admin that a stock installation.

Writing secure software

[Electrum]

Monolithic, buggy programs like sendmail will always be a security nightmare. That doesn't mean that secure code can't be written in C. qmail, for example, is completely secure. If more programmers followed good coding practices, we would see fewer security disasters. A good start would be to stop using C strings and to start using the stralloc concept.

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.