It would be nice to have someone from VMWare's technical group comment on this.
Although Continuum's comments were helpful, the impacts of modifying a Guest file's boot process seem far from simple, and frankly I have never had cause to delve into the boot processes of a vm. As an example of my uncertainty, I'm not 100% sure that whole disk encryption actually achieves the desired result. I added Truecrypt encryption to a Vista guest and tracked the boot process --- it seems that the guest is fully launched before Truecrypt kicks in, as a result any malware modification of the guest MBR would still be in place, but whether it would still be viable after Truecrypt decryption or just trash the guest is an unknown to me. I'm equally unsure whether a malware attack on an 'in-use' Guest would succeed without throwing a screen message asking if the malware could take ownership.
I'm coming to the conclusion that possibly the only effective protection would be to keep VMs in Truecrypted containers while not in use. (Put in a Truecrypt container then mount as a 'drive'.) Unfortunately that seems a very kludgy solution and I still do not know if 'in-use' vms are vulnerable.
Of course for clarity I should have stated that this is NOT a VMWare security hole, and it is only a problem if the host/server is compromised. However it would be nice to have another layer of security for things like bank access etc.
[EDIT] I experimented by setting up a Truecrypt container for a small (8GB) Windows guest. I then copied an existing Win98 guest into the mounted container (I leave you to read the Truecrypt manual if uncertain how to do this). I did NOT elect to use automount of the container. Once everything was set up I made a shortcut to the vmx file (while inside the container) then copied this to the Windows desktop. I then shutdown Truecrypt. The windows 98 guest file just appeared to be an unusually large block file. I then clicked the previously made shortcut and to my surprise the encrypted guest launched!
Some more work is needed on i/o as although I do have keyboard input to the guest, the wireless mouse does not get picked up (I did not try with a PS/2 mouse connection). All tests were conducted using the VMware 9 beta.
[EDIT] Mouse problem looks like it was due to using an old (possibly corrupt) guest that I had never previously tested with WS9 beta.
Maybe someone else can explore this further and comment on whether this provides enough protection to malware of the nature of Crisis. At first glance it looks as though it may but I do not have the forensic tools to investigate this approach.
[FINAL EDIT] I reran the Windows98SE vmguest experiment as follows:
a) Made up an 8GB container in Truecrypt
b) Mounted it
c) Installed a fresh copy of Windows98SE in the encrypted container using WS9. Tested then shut it down. USB Mouse etc worked perfectly.
d) Pulled a link outside the container
e) Provided that the encrypted container is still mounted then the link will work, but normal host file access to the container does not reveal it to be a VM guest (other than the 4 or 5 GB size). Once the container is unmounted and Truecrypt shutdown the container is tamper-proof. To run the vm, Truecrypt has to be launched and the encrypted container mounted. If the container is left mounted and the host shutdown this is the same as unmounting the container.
Conclusion, for my purposes this provides adequate malware security. I do not know if a running guest can be infected by the host (ex internal networked attacks), I suspect that guest 'locking' provides a measure of protection.
