450

No, Docker containers are not more secure than a VM. Quoting Daniel Shapira: In 2017 alone, 434 linux kernel exploits were found, and as you have seen in this post, kernel exploits can be devastating for containerized environments. This is because containers share the same kernel as the host, thus trusting the built-in protection mechanisms alone isn’t ...


132

One has to take into account why the malware is doing this distinction in the first place. Some malware does not run in the VM because the chance is high that this VM is used for inspecting the malware (i.e. some security researcher) since most normal users don't use a VM. But if everybody is using a VM then the chance is low that the VM is used for ...


90

Separate development and production It is usual practice to give developers local admin / root rights on their workstation. However, developers should only have access to development environments and never have access to live data. Sys-admins - who do have access to production - should have much more controlled workstations. Ideally, sys-admin workstations ...


79

Saying either a VM or Docker is more secure than the other is a massive over simplification. VM provides hardware virtualization; the hypervisor emulates hardware so that the guest kernel thinks it is running on its own machine. This type of virtualization is easier to isolate from one another. If your primary concern for virtualization is isolation (you ...


65

By using the same VM for browsing, word documents, and email, you are exposing all of your data to the same level of risk. Instead of doing all of this activity in the VM, consider doing your browsing and email in the VM, but the contract work and bookkeeping stuff on the host OS. That way if you get phished, the attack is limited to the VM, and can't do ...


61

If the kernel is compromised in the container, the host is compromised. Ostensibly, a compromised container should not be able to harm the host. However, container security is not great, and there are usually many vulnerabilities that allow a privileged container user to compromise the host. In this way, containers are often less secure than full virtual ...


43

(Caveat: I certainly don't claim that HAVEGE lives up to its claims. I have not checked their theory or implementation.) To get randomness, HAVEGE and similar systems feed on "physical events", and in particular on the timing of physical events. Such events include occurrences of hardware interrupts (which, in turn, gathers data about key strokes, mouse ...


42

So this answer is from the point of a developer. Keep that in mind. First, not having "local admin" rights on my own machine is a sign that I should look for a job elsewhere. It's nearly impossible to write code, fiddle with stuff, and maintain a toolchain if you have to ask permission every-time you need to update (or test out) a new dependency or ...


38

You are assuming that the intrusion is coming from the VM to the hypervisor. A VM "breakout" is when the VM accesses the host directly. An infected VM that has access to the network can attack the host's network. That's not a "breakout". But the alert in your image is indicating that it saw traffic to a domain on a watchlist. That's not ...


37

My research suggests that you have misinterpreted the meaning of the setting, e.g., see this thread. Avast is capable of using hardware-assisted virtualization to provide better anti-virus protection. However, because this can cause compatibility issues with other software, an option is provided to disable this functionality. That is, if you turn off the ...


33

No - because your VM is inside a machine connected to the Internet it is not safe. It is protected, yes, but that protection is only as good as the protection the host machine provides. An attack could compromise the host machine via its connection, subvert the hypervisor and compromise your VM. Read this question and others in the Related sidebar to the ...


28

Yes, it can. Any data stored on the virtual hard drives of the virtual machines is stored on the hard drive of the host system. When any VMs are in "suspended" state, their RAM content is also saved on the hosts hard drive. Any malware which can access these files can read and modify their content. Another attack vector would be to target the hypervisor ...


28

In theory, hardware-assisted virtualization can make hypervisor-based rootkits possible. However, this type of malware already requires extremely high privileges and is not a particular threat. Furthermore, hardware-assisted virtualization can be used by Windows to supplement its sandbox for added security. It's not a security issue so much as a feature ...


26

The references you mention don't conflict with each other. The first one claims for Meltdown that "Fully virtualized machines are not affected". The second one claims that the product is "vulnerable to Bounds Check Bypass and Branch Target Injection issues". These issues are not the Meltdown but the Spectre vulnerability. Or to summarize: CVE-2017-5753 - ...


24

As you correctly stated, Docker uses "Operating-system-level virtualization". You can think of this (if you are a *nix fan) as a fancy form of chroot. By harnessing features and functionality built into the OS, Docker acts as a director for containers. The software's view of the OS is dictated by Docker. The same kernel is used across all containers. So ...


21

Whether or not it contains an exploit, specifically, is irrelevant in the broader question of whether an OVA file can be malicious. The answer to the broader question is yes, absolutely. The Open Virtualization Format specification gives you an idea of some of the potential vectors, but the obvious one is that it could map your entire OS disk to the VM and ...


19

From a developer's point of view: Your job is to prevent change (known bugs and vulnerabilities are better than unknown, right?), but mine is to change things. This puts us at an impasse. My job is to create/change things. If your policy prevents that, then, like any other obstacle, a part of my job is finding a way around that. Which do you think is ...


18

As the article describes it, VM introspection looks like inspecting the contents of the VM in real-time, to see that everything appears to be "in order". Virtual machines allow for such inspection without consent or knowledge of the guest system. This contrasts with classic antimalware software on physical systems: the antimalware runs on the system itself, ...


18

All of this depends on the hardware (physical or virtual) available to your VM. rng-tools can only get entropy from the sources available to it. If your virtual machine has no available sources of entropy for rng-tools to use then you'll be no better off. Some virtualization systems are however able to make hardware sourced entropy available to guests ...


18

Highly customized and patched hypervisors, sandboxes around said hypervisors to mitigate breakouts, and heavy monitoring. Of course, any given server only hosts so many VMs, so a breakout is fundamentally limited to a finite number of guests, if it's able to get past the protections outside the hypervisor. For example, QEMU can be compiled with a hardened ...


18

In context of a Windows setup, a hypervisor such as VirtualBox, VMware helps isolate your guest from the host (the main installation of your OS). This is a considerate move in terms of Security, if you're dealing with activities or files/software that pose a risk to compromise your data. One example would be for Security Analysts, who is analyzing malware ...


16

Any file can contain an exploit. Whether it works or not, or if it requires a loader, is another story. For example, if there's a buffer overflow vulnerability in the processing of .ova files, then yes, it could contain an exploitable vulnerability. It all depends on whether or not you have a vulnerable application which processes the file that contains ...


16

My understanding, first off, is that the OS / hypervisor patch only mitigates Meltdown, not Spectre. Second, you patch the hypervisor to prevent a VM from reading memory belonging to the kernel of the hypervisor. You patch the guest OS to prevent a process from reading memory belonging to the kernel of the guest OS. My understanding is that they are ...


15

Escaping a virtual machine does not require skill. It only requires that: A known vulnerability exists in the VM. The attacker downloads and uses the exploit. The Internet is a fabulous thing; it allows people to do a lot of things that they don't actually understand. In any case, if you dutifully apply security updates to your VM solution (i.e. when ...


15

Think of hacking virtual machines to be the equivalent of being in a shooting range but for pentesting/offsec. It is all about practice. In the real world, how are these practices of hacking virtual machines useful? Learning & Testing of exploits/tools Understanding, Finding risks and vulnerabilities Also, the legality of these practices, you won't ...


15

TL,DR: Don't be worried, you are probably safe. Usually malware cannot escape the VM onto the host OS. There are exceptions, as some malware are designed specifically to break from the VM into the host, but those are very, very few and usually are seen on targeted attacks, not on a public internet site. Cross-OS malware infection are even rarer. Malware ...


14

A security engineer doesn't maintain computers, that's what the service desk does. In your case you will require him to install three tools: a hypervisor docker database software From there he can add and remove machines for development as much as he wants (shouldn't require a sec engineer to intervene). With regard to your "rogue container". In general ...


14

It is as safe as a Windows 8.1 machine with an internet connection. Since the VM has no network, the only way to access it would be through the host machine. If the host machine is compromised, you can consider any VM running on it to be compromised as well. The only machine completely safe from being hacked is the one that is unplugged, switched off, and ...


13

As stated above, root kits work similar on a virtual host as they do on a normal host EXCEPT that many malware/virus/rootkit authors have developed mechanisms to detect whether or not they are in a virtual machine, so they can be scripted/programmed to behave differently than they would on a normal machine. This is highly evident when reverse engineering ...


13

Amazon advisory links to the original XEN advisory on which one can read: Systems running only x86 PV guests are not vulnerable. So no problem for the PV instances. Regarding the HVM ones, Amazon explains that for performance reasons they managed to replace the HVM hardware drivers by the PV ones for storage and network operations (see PV on HVM). ...


Only top voted, non community-wiki answers of a minimum length are eligible