The gist of it: there are some flaws in the ActiveX controls VMWare installs. The possible attack scenario for these vulnerabilities looks like this:

1. The user has VMWare (or VMWare Disk Mounter for the first two vulnerabilities!_ installed
2. The user use Internet Explorer in the host machine to visit a malicious website
3. The user’s computer gets exploited

These vulnerabilities have nothing to do with a program being able to escape from the guest to the host (as many articles suggested).

Also, if you are going to link to a paper discussing serious flaws of virtualization products, at least link to Peter Ferrie’s whitepaper or the Google whitepaper (warning, PDF!). I do not wish to belittle the research done by Ed Skoudis, I consider the ideas presented in their paper too high level and only of limited effectiveness. It is only the first step in the VM-detection – VM-detection-detection race and only effective because the attackers didn’t need to come up with more sophisticated ways.

In conclusion: VM are still the safest way to study malware, however (as with everything) one needs to use a layered security approach (so at least VM’s on a separate, non-public network). Also, there is the possibility to use private-builds of the open source virtual machines (yes, open source is great!) by security researchers, effectively turning the advantage of the malware authors (the fact that defensive software is publicly available and they can study it and modify their code until it’s not detected by the current version) against them (in the sense that at this moment the malware is publicly available and the researcher can tweak her VM until it’s not detected).

Update: now here is a vulnerability with real concerns: VMware Workstation Shared Folders Directory Traversal Vulnerability (via the Pauldotcom blog). However the solution is still relatively simple: disable shared folders (you should disable all convenience features – like shared folders, networking or VMWare Tools – when working with malware to minimize the attack surface!)

Update 2: see the posting on Security Ripcord which contains a response from Ed Skoudis in the comments that reveals some additional information.

• Don’t have writable shares on the network the virtual machine is connected to. If you want to share a directory to extract file, share it from the client OS and copy it from outside
• If possible put it on a different subnet
• Use non-persistent hard disks or snapshots and revert to them regularly (currently the only commercial grade product that I know of that can do this is VMWare. QEmu also has this feature, but unfortunately it still needs some time to become a stable solution)

Following these rules you get a more secure and more convenient system than using a separate PC with something like DeepFreeze, but you loose the ability to stay logged on sites (because you loose all your cookies, history and cache).

Finally, I’m getting in synch with the released episodes. This one is relatively error-free, I have only just a few comments to make:

buffer overrun doesn’t always mean that the buffer is on the stack, it can be in the heap also. Hardware DEP prevents both kind from executing code.

Leo probably meant to say turn it on for essential Windows programs and services only instead of turn it off …

This episode is the first in which I hear Steve correcting itself, so I think this is worthy of quoting: Remember that I said last week that one of the major failings of Server was that it lacked both sound and USB support. Well, that was wrong.

They support every flavor of Linux you can imagine – FreeBSD, OS/2 Warp, Sun’s Solaris – OS/2 Warp isn’t a flavor of Linux by a long shot, but I give him the benefit of the doubt because probably he was meaning every kind of OS.

The only real problem in this podcast (netcast, sorry) is the discussion about the fixed size versus expandable drives. The state of the matter is the following: when you choose to use disks for which the space is not preallocated it saves in the file only the parts of the disk which were written too (because if the guest OS tries to read from any other area, it can just return zeros). There are two problems with this (lumped together by Steve under the name fragmentation): these disk areas are stored in a non-contiguous mode in the file, so at every access a lookup step is necessary and also there is the fact that as the file grows it itself can be fragmented on the disk. A third problem is that these files are never able to shrink. The explanation for this is the fact that the virtual machines don’t know about file systems, only about disk sectors. When a sector has been written too, it is marked as dirty and stored permanently in the file, even if the file occupying that space has been deleted. Given all this things I don’t think that Parallels’s product which probably only goes through the file system and marks the empty disk sectors is worth its price. It would be a nice extra if it was included in the program, but not as a stand-alone product.