Tag Info

Hot answers tagged

39

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


31

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


25

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


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


19

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 (web archive link). An attack requires exploiting a security issue (i.e. a programming bug which turns out to have nasty consequences) in the VM ...


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


15

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


14

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


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

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

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


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


12

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


12

If a virus is on the host machine and operates as a normal/privileged user, and a normal/privileged user on that machine can use the virtual machine, there's nothing that prevents the virus from compromising private data from the virtual machine.


11

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


11

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


11

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


10

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


9

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


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

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

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

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

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

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



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