Can malware in the guest access NON-shared folders?

[UlyssesOfEpirus]

I do not mind if shared folders are written to by any malware running in the guest, but is it possible that malware can also access folders other than the shared ones?

Can malware running in the guest do anything else to harm the host, other than messing with the contents of the shared folders?

[UlyssesOfEpirus]

We're already running an operating system. We'll abandon that operating sytem and start a new one every time we hotplug a usb drive or mount a vmdk?

[Texiwill]

Hello,

The Malware does NOT need to infect the MBR to have an infected filesystem. Some Malware infects the filesystem then jumps to other like filesystems on the machine. I would not get hung up on an infection just within the MBR, that can happen, but in more general terms other things can happen that are just as bad.

Virtualization DOES NOT solve an OS based issue, which this actually is. You do not magically become secure once you virtualize. Actually you have to worry about more issues, like cross-contamination.

VMware Virtualization creates a virtual machine container. Which means that anything that mounts this container could become infected. Anything 'shared' with this container can also become infected. This is an OS issue not specifically a virtualization issue.

There are two virtualization concepts to consider:

1. Can Malware within a VM in a hosted Environment infect the host directly (if nothing is shared), the answer is look at Cloudburst and protect against it.

2. Can Malware within a VM on a Type 1 Hypervisor infect the hypervisor (if nothing is shared), the answer is not likely. This requires a pretty ingenious not yet developed escape the VM attack to propogate.

Unrelated to Virtualization but just as important:

3. Can Malware within a VM in a hosted Environment infect the host indirectly (through some shared filesystem), the answer is YES, this is nothing new and related to how the OS handles the shares more than anything. Virtualization is not involved in this case.

You are asking if an OS has developed some way to quarantine an infection, that is what your AV should be doing and good AV is the best defense at the moment.

Best regards,
Edward L. Haletky VMware Communities User Moderator, VMware vExpert 2009

Virtualization Practice Analyst[/url]
Now Available: 'VMware vSphere(TM) and Virtual Infrastructure Security'[/url]
Also available 'VMWare ESX Server in the Enterprise'[/url]
[url=http://www.astroarch.com/wiki/index.php/Blog_Roll]SearchVMware Pro[/url]|Blue Gears[/url]|Top Virtualization Security Links[/url]|
[url=http://www.astroarch.com/wiki/index.php/Virtualization_Security_Round_Table_Podcast]Virtualization Security Round Table Podcast[/url]

[UlyssesOfEpirus]

Thanks for the replies. Since no evidence is available that mounting an infected vmdk will automatically execute malware (it is uncontrolled secret execution that matters, not the existence of an infection), it follows that mounting data-drive vmdk's is the best way to transfer data to the host and the mount tool should be recommended to anyone using a browser appliance for security. The other option is to put all data in the VM before starting, together with all your applications, and maintain backups of data .vmdk's instead of the entire VM as suggested by wila.

But then a change in one byte will cause the entire data vmdk to be copied at the next backup. Hasn't anyone at vmware developed a backup solution specialized for .vmdk's, so it only stores different bytes and not the whole .vmdk?

[Texiwill]

Hello,

Thanks for the replies. Since no evidence is available that mounting an infected vmdk will automatically execute malware (it is uncontrolled secret execution that matters, not the existence of an infection),

This really depends on the OS and filesystem, not the VMDK. If I knew the VMDK was infected, I would never mount it on the Virtualization host. If it was a Windows Filesystem I would mount it on a Linux system and visa versa, that way you have some level of trust that cross-contamination would not happen. Even so, some one could eventually break that barrier and destroy that level of trust.

it follows that mounting data-drive vmdk's is the best way to transfer data to the host and the mount tool should be recommended to anyone using a browser appliance for security.

No I would not say this is the best solution. The best solution would be to virus scan the VMDK before accessing, then access the contents of the VMDK without mounting within a program that would allow you to copy things out as needed. This way the VMDK is not actually mounted by the OS but by another tool that can control writes and what is actually executed. If there is filesystem infections, they will be containerized.

The other option is to put all data in the VM before starting, together with all your applications, and maintain backups of data .vmdk's instead of the entire VM as suggested by wila.

This is the best solution.

But then a change in one byte will cause the entire data vmdk to be copied at the next backup. Hasn't anyone at vmware developed a backup solution specialized for .vmdk's, so it only stores different bytes and not the whole .vmdk?

Veeam, PhD Virtual, and Vizioncore have all solved this problem. They currently work mainly with ESX, they may be able to work with Workstation but you would need to contact them. These tools take a snapshot, then look at the changed block list (which is stored by the VM) and only backup the actual changed blocks, reassembling the VMDK on the other side. Its one way to get fantastic throughput.

Best regards,
Edward L. Haletky VMware Communities User Moderator, VMware vExpert 2009

Virtualization Practice Analyst[/url]
Now Available: 'VMware vSphere(TM) and Virtual Infrastructure Security'[/url]
Also available 'VMWare ESX Server in the Enterprise'[/url]
[url=http://www.astroarch.com/wiki/index.php/Blog_Roll]SearchVMware Pro[/url]|Blue Gears[/url]|Top Virtualization Security Links[/url]|
[url=http://www.astroarch.com/wiki/index.php/Virtualization_Security_Round_Table_Podcast]Virtualization Security Round Table Podcast[/url]

[UlyssesOfEpirus]

What if you only back up .vmdk's and your VM gets formatted by an infection you got 2 years ago. Are you going to throw away 2 years of worth of backups and associated work?

Do you perhaps have too much faith in antivirus software and think you can scan the 2 years of backups and find the malware that the VM's antivirus missed? You can never be 100% sure with antivirus software because they are only good for somewhat widespread viruses of the past.

But if a way is found to isolate the data... you mentioned "access the contents of the VMDK without mounting". If I fill a vmdk to its maximum capacity with a given long text, will a hex editor running in the host be able to see the long text in the vmdk? Say the vmdk has got just one fully defragged FAT32 partition.

If yes, then all we need is to fill the file system to its maximum capacity with padding and copy the core bytes of the vmdk to another fresh new and clean vmdk of the same size. Demanding just one partition for simplicity. Then, mount that new vmdk, read the data, and the data is now isolated, ready to be backed up.

If all this is automated, it is superior to backing up vmdk's because you are only backing up pure data, no secret executions of malware are possible. Especially if it's just pictures and videos, as in my case.

[wila]

If all this is automated, it is superior to backing up vmdk's because you are only backing up pure data, no secret executions of malware are possible. Especially if it's just pictures and videos, as in my case.

Too bad that pictures and videos can in fact contain malware...

--

Wil

_____________________________________________________

VI-Toolkit & scripts wiki at http://www.vi-toolkit.com

[UlyssesOfEpirus]

They can contain, but can they execute? Where did you see examples of this?

[wila]

Oumpf, about every month there are bugfixes on trying to tie down code execution problems in image and video formats.

There are video formats (windows media anyone?) that actually have executing code as part of their standard capability, so for those you don't even need a huge exploit.

But if you want: examples, here's a couple I plucked of the net in a few minutes:

http://ifsec.blogspot.com/2009/10/windows-media-audio-voice-remote-code.html

http://securitytracker.com/alerts/2005/Jul/1014500.html

http://www.microsoft.com/technet/security/bulletin/ms06-078.mspx

www.microsoft.com/technet/security/Bulletin/ms09-052.mspx

www.microsoft.com/technet/security/Bulletin/MS09-051.mspx

www.microsoft.com/technet/security/Bulletin/MS09-047.mspx

www.microsoft.com/technet/security/bulletin/MS05-009.mspx

www.microsoft.com/technet/security/bulletin/ms06-039.mspx

http://osvdb.org/57802

Oh and I take no responsibility on you visiting the non official web sites... just saying..

Don't think that fixed means that it is now not having other problems..

--

Wil

_____________________________________________________

VI-Toolkit & scripts wiki at http://www.vi-toolkit.com

[UlyssesOfEpirus]

How does this compare with the number of holes for executing code in the host?

[Texiwill]

Hello,

What if you only back up .vmdk's and your VM gets formatted by an infection you got 2 years ago. Are you going to throw away 2 years of worth of backups and associated work?

The problem with backups and reasons for restoring are numerous and a common debate amoungst security specialists. If you have an infection, hack and want to restore. You should reinstall and not restore. Then in a VM perhaps, scan the VMDK and see if the virus is within any of your files before using any files from that VMDK. You would still need to use some non-mounting process to get the files out of the VMDK if there was a filesystem infection. If there were 'file' infections and they were not caught by any tools they would still exist within the files.

Do you perhaps have too much faith in antivirus software and think you can scan the 2 years of backups and find the malware that the VM's antivirus missed? You can never be 100% sure with antivirus software because they are only good for somewhat widespread viruses of the past.

No faith actually, just use this as the first step of many. There is a litany of tools that can help in this case. I have used most if not all of them when I had a similar issue.

But if a way is found to isolate the data... you mentioned "access the contents of the VMDK without mounting". If I fill a vmdk to its maximum capacity with a given long text, will a hex editor running in the host be able to see the long text in the vmdk?

Yes.

If yes, then all we need is to fill the file system to its maximum capacity with padding and copy the core bytes of the vmdk to another fresh new and clean vmdk of the same size. Demanding just one partition for simplicity. Then, mount that new vmdk, read the data, and the data is now isolated, ready to be backed up.

Not quite, writing data does not isolate the data. If the core data is infected, it remains infected.

If all this is automated, it is superior to backing up vmdk's because you are only backing up pure data, no secret executions of malware are possible. Especially if it's just pictures and videos, as in my case.

The key here is to write your 'data' to a data vmdk attached to the VM. Then just backup the data vmdk. However you are still backing up the filesystem as well as the contents. Granted this depends on how you do your backups. If you do backups from within the VM using standard Windows Backup then you are Backing up just the files. If you do backups without the VM then you are backing up the entire contents of the VMDK (filesystem + data) and whatever else is scribbled on the disk.

The question to ask yourself is what is the risk. If its low enough then almost know precautions need be used. If it is high enough then you start considering precautions and how to best get your data from the VMDK to a host safely.

Best regards,
Edward L. Haletky VMware Communities User Moderator, VMware vExpert 2009

Virtualization Practice Analyst[/url]
Now Available: 'VMware vSphere(TM) and Virtual Infrastructure Security'[/url]
Also available 'VMWare ESX Server in the Enterprise'[/url]
[url=http://www.astroarch.com/wiki/index.php/Blog_Roll]SearchVMware Pro[/url]|Blue Gears[/url]|Top Virtualization Security Links[/url]|
[url=http://www.astroarch.com/wiki/index.php/Virtualization_Security_Round_Table_Podcast]Virtualization Security Round Table Podcast[/url]

[UlyssesOfEpirus]

You wrote:

"You would still need to use some non-mounting process to get the files out of the VMDK if there was a filesystem infection."

Thank you for acknowledging that at the end of the day there is no substitute for data isolation.

What if I convert all my downloaded images to .bmp's. And all downloaded videos to uncompressed .avi's. Then copy them to the host as described above (on the host copy the core bytes of the vmdk to another fresh vmdk of the same size and mount the fresh vmdk). And finally convert all images and videos back to the original .jpg or some good .avi format like DivX. All automatically and transparently to the user. Would take time. But you can't beat that for isolation.

PS. I do have a high security risk. Even my mails have been proven to have been read by third parties. Since that incident I use lavabit.com (256 bit AES) and have been dumping my VMs more frequently.

[Texiwill]

Hello,

"You would still need to use some non-mounting process to get the files out of the VMDK if there was a filesystem infection."

Thank you for acknowledging that at the end of the day there is no substitute for data isolation.

Absolutely no substitute. The problem is how you are trying to achieve this data isolation. Just keep the data in the VMDK and never access it by the host. That is the best solution going forward.

What if I convert all my downloaded images to .bmp's. And all downloaded videos to uncompressed .avi's. Then copy them to the host as described above (on the host copy the core bytes of the vmdk to another fresh vmdk of the same size and mount the fresh vmdk). And finally convert all images and videos back to the original .jpg or some good .avi format like DivX. All automatically and transparently to the user. Would take time. But you can't beat that for isolation.

That is your choice, I think it is just too much effort to convert everything and hope that the 'conversion' process does not make things worse and that bmp and avi 's can not just be carriers for the malware. Remember, if its hidden in an image, converting it from one format to another does not necessary strip it out of the image, it just acts as a carrier. Conversion of image bits to a different format converts even the malware bits to that new format.... Of course this does depend on where the malware hooks into the existing image format.

PS. I do have a high security risk. Even my mails have been proven to have been read by third parties. Since that incident I use lavabit.com (256 bit AES) and have been dumping my VMs more frequently.

In this case, I would not bother with doing anything in your host. I would stick to working within your VM entirely and backing up that VM regularly. Never mount your VMDKs within your host, etc.... BTW, email is inherently insecure as it is a store and forward technology. Anyone on the machine that stores the email before forwarding can read anyone's email with the proper permissions of course.

Best regards,
Edward L. Haletky VMware Communities User Moderator, VMware vExpert 2009

Virtualization Practice Analyst[/url]
Now Available: 'VMware vSphere(TM) and Virtual Infrastructure Security'[/url]
Also available 'VMWare ESX Server in the Enterprise'[/url]
[url=http://www.astroarch.com/wiki/index.php/Blog_Roll]SearchVMware Pro[/url]|Blue Gears[/url]|Top Virtualization Security Links[/url]|
[url=http://www.astroarch.com/wiki/index.php/Virtualization_Security_Round_Table_Podcast]Virtualization Security Round Table Podcast[/url]

[UlyssesOfEpirus]

"Conversion of image bits to a different format converts even the malware bits to that new format...."

Obviously you haven't read the jpeg link provided by wila so do not see the reasoning for going to the rawest and simplest possible format. It's about programming. With a very simple format like .bmp (just a 2D array of values after a header), it is easy to write solid software around it. Solid as in exploit-free.

[Texiwill]

Hello,

If the Malware is embedded in the actual picture and not a hook off some other part of the code, your BMP conversion tool would not know this, unless you have figured out how to undo stegnography, then the Malware is just transferred with the other bits of the image. When you reconvert, the malware still exists within the image. So the BMP becomes just a carrier... The question is then, can the new 'JPG' execute any of that malware.... I am not sure... I imagine it would not be able to do so unless something else came along and rehooked up the pointers, etc.

Best regards,
Edward L. Haletky VMware Communities User Moderator, VMware vExpert 2009

Virtualization Practice Analyst[/url]
Now Available: 'VMware vSphere(TM) and Virtual Infrastructure Security'[/url]
Also available 'VMWare ESX Server in the Enterprise'[/url]
[url=http://www.astroarch.com/wiki/index.php/Blog_Roll]SearchVMware Pro[/url]|Blue Gears[/url]|Top Virtualization Security Links[/url]|
[url=http://www.astroarch.com/wiki/index.php/Virtualization_Security_Round_Table_Podcast]Virtualization Security Round Table Podcast[/url]

[UlyssesOfEpirus]

For the record, I have found that in linux there is no such thing as a boot sector virus - when you mount a disk no execution of machine code in the MBR occurs.

In other words, you can mount a .vmdk in linux without carrying infections. File infections too are rare and severely limited in a linux host, there's extremely few that can self-reproduce, and even those cannot do much damage, because only the root account has full access.

[Texiwill]

Hello,

Yes, that is true, Linux is a good alternative, however, even so before I mounted a LInux disk on Windows I would run things like chkrootkit, clamav, or another AV tool. Remember, Linux can be a carrier for windows virus'... Think how Samba works....

Best regards,
Edward L. Haletky VMware Communities User Moderator, VMware vExpert 2009

Virtualization Practice Analyst[/url]
Now Available: 'VMware vSphere(TM) and Virtual Infrastructure Security'[/url]
Also available 'VMWare ESX Server in the Enterprise'[/url]
[url=http://www.astroarch.com/wiki/index.php/Blog_Roll]SearchVMware Pro[/url]|Blue Gears[/url]|Top Virtualization Security Links[/url]|
[url=http://www.astroarch.com/wiki/index.php/Virtualization_Security_Round_Table_Podcast]Virtualization Security Round Table Podcast[/url]

[UlyssesOfEpirus]

You're talking about mounting a linux disk on windows but the recommendation was the opposite, to mount a windows disk on a linux host. Or any other disk on a linux host. No automatic transmission of the infection happens when you mount an infected .vmdk on a linux host.

On the other hand, any data that contains malware cannot do real damage in linux. And crucially, if you ever open the data from a windows guest, it is the same as opening the data off a .vmdk backup because data that is hiding malware will execute its dirty job either way. So there is no benefit in doing .vmdk backups, file backups are better because they filter out boot sector infections, if done on a linux host.

[wila]

Hi,

>File infections too are rare and severely limited in a linux host, there's extremely few that can self-reproduce, and even those cannot do much damage, because only the root account has full access

I've heard that excuse so much.. a virus doesn't need root access to do a lot of damage. It can do everything your current user can do. Most of the times that means access to the internet, read/write access to any file the user can access. Running scripts... it can do a lot more as you like it to do.

Exploits can be operating system agnostic or work on many if they use the right vector. For example a flash or pdf exploit can work for more as just windows and if it happens to give root... then it can do anything it wants with your box.

Yes linux is much less prone for this, but it sure isn't impossible to get rooted or get a worm infestation of some kind.

The same counts for OS X, no OS is fail proof.

I also don't know why you are so hung up on MBR viruses, an infected file system != MBR infection. It could be in meta data, it can be autorun files, it can be hidden as filesystem corruption that contains the malware, there are so many possibilities...

--

Wil

_____________________________________________________

VI-Toolkit & scripts wiki at http://www.vi-toolkit.com

[Texiwill]

Hello,

As Wila stated, we are not commenting much about MBR virus' as there are so many others that come into play that will cause you issues! By opening Linux on windows or Windows on Linux you may be transferring data that contains a virus and therefore Linux becomes a carrier. Once its on a windows box the virus is STILL there.

Keep it all within your VMDK and just backup the VMDK. Ignore host filesystems of any type.

Best regards,
Edward L. Haletky VMware Communities User Moderator, VMware vExpert 2009

Virtualization Practice Analyst[/url]
Now Available: 'VMware vSphere(TM) and Virtual Infrastructure Security'[/url]
Also available 'VMWare ESX Server in the Enterprise'[/url]
[url=http://www.astroarch.com/wiki/index.php/Blog_Roll]SearchVMware Pro[/url]|Blue Gears[/url]|Top Virtualization Security Links[/url]|
[url=http://www.astroarch.com/wiki/index.php/Virtualization_Security_Round_Table_Podcast]Virtualization Security Round Table Podcast[/url]

[UlyssesOfEpirus]

Texiwill I think you missed the point wila was making about focusing on the MBR, he was talking about alternatives to MBR infections that are not in the data either and I therefore had not considered them.

And wila, I'm sure you know that when you copy a file from a mounted .vmdk, you're not copying metadata, and metadata is filtered out just like the MBR is filtered out because if metadata is broken so that windows gets a buffer-overflow and passes execution to malware, that is a fault of the windows implementation and not the linux implementation of NTFS journals, say. Such a windows exploit of NTFS metadata, but which is also an exploit for the linux implementation of NTFS metadata, remains to be seen.

Or you use FAT32 for the data .vmdk and the chances of this improbable double-exploit get even less. Because FAT32 is so simple that probably no exploits exist for its windows implementation, let alone double-exploits for both linux and windows or both ESXi and windows.

Autoruns in the data .vmdk are only autoruns if the system treats them as autoruns, ie if the system disk is infected. When you put the data back to a fresh VM any autorun will no longer be an autorun because the system disk is clean. Effectively the autorunness is filtered out just like the MBR is filtered out.

In conclusion, if you have a policy of never opening files that come from .vmdk's, but only copying them eg for backup purposes, and using linux/ESXi as the host, then the host cannot be infected. An infection that cannot run, is not an infection, as far as the status of the host is concerned.

Whereas if you keep backups of .vmdk's, you're keeping a history of infections of the filing system that keep building up.

And hoping that your collection of 20 antivirus tools will never miss an infection that the VM's antivirus tool missed. Not that there's anything wrong with scanning .vmdk's on a VM with many antimalware tools.

There's no substitute for isolating data. And the best way to do it is by mounting .vmdk's in a linux/ESXi host and copying just the files that we recognize. And only copying the files, never opening them in the host.[/b]