Tag Info

Hot answers tagged

29

VM's can definitely cross over. Usually you have them networked, so any malware with a network component (i.e. worms) will propagate to wherever their addressing/routing allows them to. Regular viruses tend to only operate in usermode, so while they couldn't communicate overtly, they could still set up a covert channel. If you are sharing CPU's, a busy ...


24

There have been some white-papers published over the years describing ways that researchers have managed to infest a host OS from a VM. These are usually seen, rightly so, as security vulnerabilities by the VM vendors and treated as such. Since I first saw those papers, Intel has made some significant processor instruction-set improvements in allowing ...


24

There is no simple answer to this question. VM software is still software and has vulnerabilities that can be targeted and thus, in theory at least, exploited to do more harm. Running an infected VM with access to your network also opens up potential attack vectors. Another interesting point to consider is that sufficiently advanced malware could be ...


22

The host machine can impact and alter whatever it wishes in the guest VM. The host can read and write all the memory of the guest, stop and restart it on a per-instruction basis, and, by nature, sees every single data byte which enters or exits the guest. There is nothing which the OS in a guest VM can do to protect itself against an hostile host. Thus, if ...


17

Firstly, there is no guarantee you'll even be able to run a VM inside a VM. It may seem obvious but it is by no means certain it will even work. This is because VM's may rely on virtualization features of your hardware which are not exposed inside the VM itself. Secondly, why two, why not three, four, five, etc... There is such a thing as overkill security. ...


16

Theoretically, the guest system is totally isolated by the VM and cannot even "see" the host, let alone attack it; so the guest cannot break out of the VM. Of course, in practice, it has occasionally happened. An attack requires exploiting a security issue (i.e. a programming bug which turns out to have nasty consequences) in the VM implementation or, ...


14

Tor does not always protect your ip fully when you need to interact with the end node. You can check your efforts with online checks like this. What has worked for me on every check I've tried is JanusVM. It runs as a VM, which you use as a proxy for your hardened browser VM. Janus uses Tor, squid, dns-proxy-tor, and privoxy to cover your ip. It is very ...


13

An example of guest-to-host code execution can be found in the Cloudburst exploit. There is a video demonstrating it and a paper from Immunity detailing their success on VMware Workstation 6.5.0 build­118166 on a Windows Vista SP1, VMware Workstation 6.5.1 build­126130 on a Windows Vista SP1, and (even more scary) VMware ESX Server 4.0.0 build­133495. This ...


13

I have not yet seen any in-the-wild malware that was designed to infect a host machine from within a VM. I expect that most malware simply wouldn't care whether it is running on the bare hardware or within a VM since it can achieve its goals equally well in both cases. It's probably safe to assume that malware won't escape a VM simply because it has no ...


13

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, ...


12

Yes, if you strictly bond yourself to some (absolutely sane) security rules: Use a completely different operating system for the host and for the guest. For example, malwares which will infect your Windows guest are unlikely to infect or even attack your Linux host. Do not use similar operating systems on your network than the guest. Again, your Windows ...


11

Using a virtual machine is a safer way to study malware than running it on a normal machine - the main reason being that you can wipe and start over from a known fresh image at any time. Isolation is also key, though - if your virtual machines are connected to your network they will be able to spread malware just as if they were physical machines, so either ...


10

Xen, by definition, is virtualized. It assumes a specific guest code for the operating system kernel. It does not try to hide the presence of virtualization, it actually advertises it plainly. This is not the VM you are looking for. A fully invisible hypervisor is theoretically feasible, but not cheap. The problem is with timing. An hypervisor works by ...


10

(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 ...


9

A virtual machine is exactly that, a logically separate machine, so it must have the same security layers placed on it as you would a bare-metal system. Using a virtual machine will not stop a vul if it uses normal channels to get to the host machine. The real beauty in virtualization is the ability to roll back VMs to a state where they were not effected, ...


9

You should use a live cd like BackTrack. This comes with TOR and software for breaking WEP and WPA2-PSK. Then you can go war driving... are you old enough to drive? Also brush up on your OSI model, the MAC address is only needed by the data link layer and is there for scrubbed off by whatever router you are behind. However, some routers log what MAC ...


9

If you're running a VM and it isn't filtered by the firewall, then it's probably operating in a bridged mode at L2 below the firewall's view of packets. To diagram: network card --|-- firewall ---- applications | VM If you're talking about Linux, then a Serverfault question discusses this as well, and there are kernel ...


8

Legalities and ethics aside, the following could theoretically provide a reasonable level of anonymity: A Live CD, e.g. one of the Linux variants An internet connection not owned or traceable to you, e.g. an unsecured WiFi connection An SSL VPN with an exit point in a country with laws to protect your information and purchased anonymously e.g. by mail ...


8

Everything: As root, just do this: rm /dev/random mknod /dev/random c 1 9 Now /dev/random will actually access the same underlying logic as /dev/urandom. After this change, both /dev/random and /dev/urandom will draw from the non-blocking pool. The non-blocking pool will draw from the blocking pool, which the system will still fill.


8

Answer first, then why: A virtual machine can be more secure. From a practical standpoint, there exists code and malware that can infect both boot partitions, BIOS, and also hardware devices. So, a VM has slightly more advantages in a reduced attack surface from a generic point of view - potential VM hopping code is the largest one specific to the VM. ...


8

The short answer is: No, this would not be an ideal or foolproof way to study a virus. If the virus is designed to break out of the VM, there is no reason to believe it would stop at doing that once. For all you know, it might test whether it is run inside a second VM and break out of that one, too. That does not require much more sophistication than ...


8

Isolating the browser in a specific jail that it cannot escape is meant to contain damage: if the browser is hijacked, at least the attacker will not obtain immediate access to the rest of the machine. However, whoever hijacks a Web browser can do everything that the Web browser normally does, including accessing your Web secrets (cookies, stored passwords), ...


8

Virtualization offers some layer of isolation. In your "B" case, if (for instance) there is a remotely exploitable hole in the SMTP server, then an attacker who exploits it may gain full control of the virtual machine which runs that SMTP server, but he will still be "outside" of the two other machines (the guest with the Web server, and the host). This may ...


7

First of all, I assume that you have already located the IP address of the attacker, using an IDS for example. In this case: Are there ways to determine that the attacker is using a VM at all? One way I can think of, provided you have the IP, is to find the MAC of the attacker. Usually it will point to the manufacturer, which will be vmware or some ...


7

You don't say why you would care whether the attacker is using a VM. I'd say it is irrelevant. It's just a distraction. So I'd unask that part of the question. As for how to tell what machine on the network is the host system, your ability to do this in this special situation is about as good as the situation when there is no VM. You have DHCP and ARP ...


7

To protect your VM, you really have three options. Each of them is probably equal to the other in terms of security, provided that you use them properly. Whole-disk encryption within the VM. Never save the VM machine state - always shut it down completely. Do not use the host system's sleep, suspend, or hibernate functions while the VM is running. Wrap ...


6

Trusted Execution Technology is coupled with a collection of security features available on the modern Intel chipset. The Trusted Platform Module (TPM) and other DRM like features are also in this bundle. The reasoning behind this is because of abstraction, which is more commonly attributed to a software architecture. The commonality behind all of these ...



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