We often say, “HTTPS is secure,” or “HTTP is not secure.” But what we mean is that “HTTPS is hard to snoop and makes man-in-the-middle attacks difficult” or “my grandmother has no trouble snooping HTTP.”
Nevertheless, HTTPS has been hacked, and under some circumstances, HTTP is secure enough. Furthermore, if I discover an exploitable defect in a common implementation supporting HTTPS (think OpenSSL and Heartbleed), HTTPS can become a hacking gateway until the implementation is corrected.
HTTP and HTTPS are protocols defined in IETF RFCs 7230-7237 and 2828. HTTPS was designed as a secure HTTP, but saying HTTPS is secure and HTTP is not still hides important exceptions.
Virtual machines (VMs) and containers are less rigorously defined, and neither was intentionally designed to be more secure than the other. Therefore, the security issues are still murkier.
Why I believe VMs are more secure than containers
Divide and conquer is a winning strategy in war and software. When an architecture divides a single complex, hard-to-solve security problem into easier problems, the result will, in most cases, be more secure than a single solution that addresses all problems.
Containers are an example of divide-and-conquer applied horizontally to applications. By locking each application in its own jail, the weaknesses in one application do not weaken applications in other containers. VMs also divide and conquer, but they go a step further in isolation.
Marvin Waschke/IDGA flaw in a jailed application cannot affect other applications directly, but the jailed application can break the single operating system (OS) shared with other containers and affect all the containers. With a shared OS, flaws at any point in the application, container, and OS implementation stack can invalidate the security of the entire stack and compromise the physical machine.
+ Also on Network World: Which is cheaper: Containers or virtual machines? +
A layered architecture like virtualization separates the execution stack of each application all the way down to the hardware, eliminating the possibility of applications interfering with one another through the shared OS. In addition, the interface between each application stack and the hardware is defined and limited to prevent abuse. This provides an additional robust perimeter for protecting applications from one another.
VMs separate the OS that controls user activity from the hypervisor that controls interaction between the guest OS and the hardware. The VM guest OS controls user activity but not hardware interaction. A flaw in an application or the guest OS is unlikely to affect the physical hardware or other VMs. When the VM guest OS and the OS supporting a container are identical, which is often the case, the same vulnerability that will compromise all other containers running on the OS will not jeopardize other VMs. Thus, VMs separate applications horizontally and also vertically separate OSs from hardware.
VM overhead
The extra security of VMs comes at an expense. Control transfer is always costly in computing systems, both in processor cycles and other resources. Execution stacks are stored and reset, external operations may have to be paused or allowed to complete, and so on.
Shifts between the guest OS and the hypervisor cost a lot and happen often. Even with special control instructions burned into the processor chips, the control transfer overhead decreases the overall efficiency of VMs. Is the decrease significant? Difficult question. Applications can be tuned to reduce the overhead by managing control transfer, and most server processors are now designed to streamline control transfer. In other words, the significance depends on the application and the server, but the overhead can never be completely eliminated, only abated.
Hypervisor vulnerabilities
To further complicate matters, separating layers in a VM architecture raises another specter: hypervisor flaws. A hypervisor breach is a single point of failure with potential for vast consequences, especially in public clouds. Conceivably, a single hacker could launch code in a VM that takes control of applications owned by other public cloud consumers, pwning a tranch of a public cloud in a single exploit.
A rock-solid architecture can still have implementation defects that weaken a system substantially. Hypervisor breaches are often fobbed off by claiming they will never happen: The story goes that hypervisors are so simple, so well-written, so carefully vetted that they never fail. A hypervisor breach might be as devastating as WannaCry, but don’t worry about it. But Heartbleed happened. And OpenSSL has far fewer lines of code than a hypervisor. I need to go out now—my flying pig wants more hogwash.
I don’t know of any significant hypervisor breaches to date. But a quick look at the Common Vulnerabilities and Exposures (CVE) database reveals that researchers do find exploitable hypervisor weaknesses. The hypervisor developers and vendors have been quick to patch vulnerabilities as they occur. In March 2017, Microsoft issued Security Bulletin MS17-008, documenting seven patched vulnerabilities in its Hyper-V hypervisor, all designated important or critical.
I still believe VMs provide better security than containers, but we have to look at the safety of VM systems with clear eyes. I plan to discuss hypervisor weaknesses in more detail in the future. Also, containers and VMs are often combined. There is much yet to be said.