What technology is more secure? Many people think that virtual machines are more secure. In theory, yes, but in practice … there are doubts.

We often hear statements such as, “HTTPS is well protected,” or “HTTP is not secure.” However, what do we mean by these phrases? “It is difficult to track down and launch a MITM attack on HTTPS” or “My grandmother has no problem tracking HTTP.”

Those phrases might very well prove wrong because HTTPS can be hacked. There have been many such cases. It is also true that HTTP can be quite safe under some circumstances. Also, if you find an exploitable vulnerability in a common implementation that supports HTTPS (meaning OpenSSL and Heartbleed), then this HTTPS can become a hacker gateway until the entire system is fixed.

HTTP and HTTPS are protocols defined by the Internet Engineering Task Force (IETF) in RFC documents, No. 7230 to 7237 and 2828. HTTP appeared first, and as early as 2000, HTTPS was created as a more secure variant of HTTP. However, claiming HTTPS is secure, and HTTP is not would not be correct since exceptions do exist.

Why virtual machines are safer than containers

Divide and Conquer is a winning principle not only for military strategy but also for software. When an architecture allows dividing one big, complex, intractable security problem into smaller tasks, the result of solving each component will in most cases be a safer option than in a situation where there is one solution that will be used to address all problems.

Containers make a striking example of that principle. Because each application is isolated in its own “cell,” flaws in one application do not weaken applications in other containers. Virtual machines are also based on this principle, but in this case, each action takes place in isolation.


Working with a container implies the following risk: weak point or failure in an application confined in a cell cannot affect other applications directly, but such a failed application may cause damage to the common\shared Operating System that the other containers also use. Therefore, the adverse impacts now spread to all the containers. Given all this, we can conclude that when using a common\shared OS, the entire structure is exposed to risks if a malfunction occurs in at least one of its components. That is to say, if at least one component undergoes negative influence, then this puts the physical machine at risk.

A multi-tiered architecture, such as the virtualization of Windows servers, separates the stack of each application’s work up to the hardware level, excluding the possibility for applications to interact with each other via a shared OS. Moreover, there are clear borders between a stack of the applications and the hardware established with the goal of preventing any further errors and incorrect usage. All this provides additional reliability and protection, preventing applications from adversely affecting each other. Virtual machines separate the OS, which controls the user’s activities, from the Hypervisor, which controls the interaction between the guest OS and the hardware. The guest OS of the virtual machine manages the user’s actions, but not the interaction with the hardware. Errors occurring in any application or guest OS are unlikely to affect physical hardware or other virtual machines.

If we are to compare two identical OS’s (guest OS of the virtual machine and the OS of the container), then any external threat would affect all the containers operating on the OS while no threat will be detected for virtual machines. The reason for that is that virtual machines use a method when applications are separated horizontally, while the OS is separated from the hardware vertically.

Ethical Hacking Training – Resources (InfoSec)

Hypervisor vulnerabilities

However, let’s get back to the title of this article, are virtual machines better? No, they are not. A threat might emerge even in an architecture, which provides for the isolation of all layers. The weak point in this architecture is the Hypervisor. The malfunctioning hypervisor is a single point of failure that may shut down the entire system or render data inaccessible, which is of particular concern in public clouds. Therefore, that may readily create conditions when a hacker is launching a malicious code on a virtual machine administrated by another application, which is owned by a public cloud user, and thus such a single attack enables him to take over all the public cloud data.

An architecture with a strong structure can still have implementation errors that significantly weaken the system. Malfunctioning of the hypervisor is not given proper attention too often because there is a strong belief that nothing will ever happen to it. After all, it is believed that hypervisors are so simple, so well written, so thoroughly checked that they never fail. However, the consequences of errors in the operation of the hypervisor can be just as devastating as the infamous consequences of the WannaCry virus. By the way, let’s also recall the infamous Heartbleed, an error in the OpenSSL cryptographic software. Mind that OpenSSL consists of far fewer code lines than a hypervisor. However, do not worry about it yet.

As of today, no evidence whatsoever suggests any high-profile and serious hypervisor malfunctioning has ever exposed entire system to the risk. However, a quick analysis of the Common Vulnerabilities and Exposures database (CVE) shows that researchers are regularly discovering new shortcomings in hypervisor operations that negatively affect the technology. Meanwhile, developers shall have their due as they are prompt in coming up with the solutions fixing system vulnerabilities as those emerge and get spotted. In March 2017, Microsoft released MS17-008 Security Bulletin listing seven fixed vulnerabilities in Hyper-V, all of which were rated as critical or serious.

In conclusion, we can say that, based on practical use and theoretical knowledge, virtual machines still provide better security than containers. Meanwhile, we should not take a rose-colored view of virtual machines security and always be on guard. Besides, containers and virtual machines often get combined, which is a matter for further long discussions to be anticipated.