Virtual Machines are No Security Blanket

Contrary to popular belief, virtual machines are no more secure than physical machines. They are also no less so.

I’m asked at least three or four times a year about virtual machines and security. Invariably, the dialog goes something like this from a colleague I’ll refer to as Jim:

Jim: “Hey, I’m thinking of moving my physical machines to virtual ones. What do you think of that?”

Ken: “It’s a great idea, you’ll save a lot of money and you’ll love the provisioning speed, ability to move workloads around, snapshots and I could go on and on.”

Jim: “What about security? You didn’t mention security.”

Ken: “What about security?”

Jim: “Well, I’m hoping to make my systems more secure by recreating them as virtual machines.”

Ken: “It won’t work. Virtual machines are no more secure than physical ones.”

Jim: “Maybe I should rethink moving to virtual machines.”

Ken: “No, maybe you should just rethink why you want to move to virtual machines.”

There are good reasons for moving to virtualization but security isn’t one of them. Virtual machines are no more or less secure than physical machines. It’s pure fantasy or what most Internetnicks call “FUD” (Fear, Uncertainty and Doubt). A good example of this misconception is an article I read a few days ago that described how to steal a virtual machine and its data. The author describes how someone with administrative access can easily steal a virtual machine.

The author did a fine job in describing how to do this. I have no problems with the article or the author. However, the uninformed reader might assume that a virtual machine somehow allows an administrator better access to a system and its data. This is not true.

The operative word in this concept is administrator. Administrators have unlimited access to the systems they administer whether they are physical or virtual. As a business owner, you entrust your systems, your data and your secrets to the person(s) with root or Administrator access. Such a person can touch, look at and steal every bit of data on your systems—physical or virtual.

Virtual systems have the same three major security concerns as physical systems: Users, Services and Files.


Having user accounts on a computer system poses a security risk. Users who use weak or predictable passwords, write down their passwords, “loan” their passwords or have malicious intent pose the greatest threat to systems. Once an attacker compromises a user account, the effort required to crack the administrative account and gain access to the whole system has decreased significantly. In system administrative parlance, users are “a necessary evil”.

Administrators (those who hold the password to the root account) have no limitations on what they may view, change or remove from a system. There are no files or processes protected from the administrative user. The administrative user, or an attacker with equivalent access, may take any action against the system including; copying data, removing files, killing processes or leaving the system in an unusable state.


System administrators will also tell you that services provide an excellent path into a system for wanton attackers. They begin by scanning your systems for listening ports (services) that may be unguarded, unpatched or wholly ignored by administrators. A service is a daemon that runs in memory and “listens” for TCP/IP connections on a port number as typically defined in /etc/services. These ports allow communications from a client application, on a remote system, to the listening port on your system. For example, the incoming mail service, POP3, listens on port 110 by default. If a listening service has vulnerabilities, it is an opportunity for exploitation.

When an attacker locates one such service, he goes to work to glitch that service and present himself with an opening to a user account—hopefully one with elevated privileges—or at the least one with a usable shell.

Virtual machines have listening ports for their services just as physical ones do. There is absolutely no difference in the quality, security or stability of one over the other. In the virtual world, as well as the physical, administrators must prune the number of services running on a host to the minimum number possible. Turning off superfluous services decreases the exploitable footprint of the system.

Maintaining a system that’s current on all security patches and service packs, also helps protect it from compromise.


Every collection of bits on a *nix filesystem is a file. Directories are files. Executables are files. Scripts are files. Everything is a file. Virtual machines have filesystems as do physical ones. So, how can a simple file pose a security threat to a system? Permissions. Permission rule the *nix galaxy. Permissions determine who can see a file, change into a directory, execute a file, remove a file and execute a file with special privileges (setuid and setgid).

Incorrectly set permissions can allow exploitation of vulnerabilities in programs that aren’t designed well or those that haven’t received security updates. In *nix systems, certain programs have the ability to allow you to use them with temporary elevated privileges. A good example is the passwd program. You run passwd to change your system password but to do so, the passwd program must update the /etc/shadow file with your new password. The problem is that the /etc/shadow file’s permissions restrict all but the root user. Temporarily, the passwd program elevates your privileges long enough to allow your new password to update the /etc/shadow file. During that momentary security lapse, an attacker could break the process and gain root access to the system.

Fortunately, most system functions have programming in place to circumvent this activity. Programming techniques such as privilege separation, privilege bracketing and dropping root help prevent these types of exploits.

System security and backups are the two highest priorities for system administrators. Good administrators will run periodic network and local vulnerability scans to check for exploitable code. They’ll also maintain a regular patch and maintenance program to secure their systems. I hope you understand from this discussion that virtual machines have no more and no fewer security concerns than physical machines. Security is a concern for all systems regardless of operating system, location or status. System security requires constant vigilance but if you have a renegade administrator in your midst, all bets are off.

Comments on "Virtual Machines are No Security Blanket"


Do you believe you have complete control over your system now, virtual or not? I bet I could come up with a logic that could define a virtual machine that a sys admin maintains, and another system that an end user uses and neither would actually have control of either system and I could rewrite protocols so that data was a heck of a lot more secure across the entire nation.


Virtual machines are no more or less secure than physical machines

That\’s just plain wrong, virtual machines are far less secure than physical ones!

Virtualization software, as any other software, has bugs and these bugs can be exploited to take control of the VM process allowing execution of arbitrary code in the host. That would give an attacker full access to any sibling VMs running there.

Hardware also has bugs but hitting them will usually just leave you with a crashed machine instead of allowing you to access other servers in the neighborhood.

Some real examples:



Virtual machines have the one great advantage of effortless snapshots and easy provisioning. So while they are not any more secure than physical servers, recovery from an attack is much easier and quicker: Locate a snapshot from before the attack, spin it up in the lab (behind a firewall or off the net entirely), close the loophole, move it online, and you\’re back in business. The big unknown in this scenario is \”close the loophole\”, of course.


This is just about as dumb an article as I have ever seen. Anytime you add anything to the mix it is probably less secure period.

Also, just restoring a machine doesn\’t get you back to where you were, unless your just displaying a few flat web pages. I guess I think in terms of actually doing something – like taking orders.



Well, the first link you gave is for: Penetration-testing company Immunity has exploited a flaw in VMware software that allows malicious code running in a virtual machine to take over the host operating system. This would be similar to the LSASS worm killing other physical machines on a network of physical machines. This doesn\’t make the VM less secure.

And, same for the other one: \”This is indeed a guest-to-host exploit,\” Kortchinsky said in an e-mail, according to a Computerworld report. \”It uses several vulnerabilities in the \’Display functions\’ (as VMware put it) that allow [someone] to read and write arbitrary memory in the host. Thus, the guest can run some code on the host, effectively bypassing ASLR and DEP on Vista SP1.\”

Again, not VM security issues.


You\’re correct. You\’d have to do that with a physical machine as well.

The VM itself is not less secure just because of its status as a VM.


@khess, obviously you don\’t understand the implications of a guest to host exploit!


Hello there! Would you mind if I share your blog with my twitter group? There’s a lot of people that I think would really appreciate your content. Please let me know. Thanks


825468 685741As soon as I found this web site I went on reddit to share some of the love with them. 658321


Leave a Reply

Your email address will not be published. Required fields are marked *


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>