VMware Cloud Community
UlyssesOfEpirus
Enthusiast
Enthusiast

Would qemu or openvz perhaps be more secure than vmware?

For the purposes of basic, basic usage of vmware, in my case just a guest connected to the internet and a host connected to absolutely nothing (no networking functionality at all at the host, any transfers to be done via a usb flash drive or the .vmdk mount tool):

1. Would using qemu instead of vmware perhaps make it harder for a hacker to penetrate the host from the guest?

2. Would OpenVZ perhaps make it harder to penetrate the host?

If vmware is so much more widely used than the other two, wouldn't it have the same problem that microsoft internet explorer has compared to opera browser, namely that there's a larger number of computers using it therefore it would give a better return on investment to hackers trying to find exploits for it, therefore much more exploits available for vmware at any given time?

Reply
0 Kudos
17 Replies
azn2kew
Champion
Champion

As far as I know, VMware is still secure and haven't seen major attacks within the hypervisor themselves, but minor security bug back with the VMware workstation otherwise its pretty secure and stabe for us and they are moving away of using Service Console too. That doesn't mean no one can penetrate or hacks the product itselve and maybe someone out there trying to sneak and test to penetrate it and as you mentioned, once VMware became the giant virtualization solution it will definitely excited hackers to pay more attention. Remember VMware has gained EAL4+ highest government security level and you can certain and relief that VMware spent tons of resources and development to their product and they would do anything to protect them. You should receive random updates on products patches and revisions and those are just features improvement and enhancement and minor security concerns but still vulnerable who knows. No one make perfect product whatsoever on this planet. If its a human made product its vulnerable at some level.

I haven't use OpenVMZ or qemu to comment on their security standards but I would be very comfortable with VMware hypervisor anytime as long as I utilize security guide best practices from Tripwire, STIG, CIS, VMware, etc...and lock down as much as you can and integrated with vShield Zone, or 3rd party products like HyTrust other other IDS appliances.

If you found this information useful, please consider awarding points for "Correct" or "Helpful". Thanks!!!

Regards,

Stefan Nguyen

VMware vExpert 2009

iGeek Systems Inc.

VMware, Citrix, Microsoft Consultant

If you found this information useful, please consider awarding points for "Correct" or "Helpful". Thanks!!! Regards, Stefan Nguyen VMware vExpert 2009 iGeek Systems Inc. VMware vExpert, VCP 3 & 4, VSP, VTSP, CCA, CCEA, CCNA, MCSA, EMCSE, EMCISA
Texiwill
Leadership
Leadership

Hello,

1. Would using qemu instead of vmware perhaps make it harder for a hacker to penetrate the host from the guest?

There is no way to get from the Guest to the Host (server, workstation, fusion, player) or the hypervisor (ESX, ESXi) unless you BADLY configure the virtualization host. I.e. in Workstation and Fusion, if you enable VMware HGFS (a file server) then this possibility exists. But if you NEVER configure VMware HGFS (again only available on Workstation and Fusion), then Workstation is as secure as all the other products from VMware. There is no way (at the moment) to escape the VM through the VM. Networking issues still exist of course.

Qemu is used by Xen for some things, KVM uses it as well. Is it more secure than VMware? Perhaps, I think the weakness if anything depends on how the network is implemented. The network makes use of a iptables bridge (Workstation, Fusion, Player, Server all do this as well). Hosted virtualization imply that the host can see the packets destined for a VM and if the host is compromised so is the VM. The packets destined for the VM are quite readable by the host.

For ESX it takes much more difficult as the service console can not actually read any NIC but its own.

2. Would OpenVZ perhaps make it harder to penetrate the host?

I do not think so, OpenVZ containerizes Apps within the host. Therefore you are still writing files to the host and not to a self contained virtual disk. If those files have a virus AND your Host accesses one of these files, well things could happen. So I do not think this option as as secure are running within a virtual machine. I am sure the OpenVZ folks would disagree but if you 'write' to the same file systems the host can access then the host is at risk.

If vmware is so much more widely used than the other two, wouldn't it have the same problem that microsoft internet explorer has compared to opera browser, namely that there's a larger number of computers using it therefore it would give a better return on investment to hackers trying to find exploits for it, therefore much more exploits available for vmware at any given time?

Perhaps but I do not think so. Security by obscurity or using little used programs does not mean you are any more secure. Unlike VMware the qemu/OpenVZ have their source available which means someone could find a security issue much easier.


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: Securing the Virtual Environment'[/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]|Virtualization Security Round Table Podcast[/url]

--
Edward L. Haletky
vExpert XIV: 2009-2023,
VMTN Community Moderator
vSphere Upgrade Saga: https://www.astroarch.com/blogs
GitHub Repo: https://github.com/Texiwill
UlyssesOfEpirus
Enthusiast
Enthusiast

The player has a menu option where you can set Shared Folders to Disabled, and by default it is set to Disabled. Is that enough in terms of disabling VMware HGFS, or is it not the same thing?

Do I also need to change anything in the config.ini or .vmx options in order to isolate the host as much as possible? No vmware tools will be installed in the guest.

"I would be very comfortable with VMware hypervisor anytime as long as I utilize security guide best practices from Tripwire, STIG, CIS, VMware, etc...and lock down as much as you can and integrated with vShield Zone, or 3rd party products like HyTrust other other IDS appliances."

For the purposes of my extremely simple setup, is it enough that I physically remove from the host all network adapters and all virtual network adapters from the host AND the guest, and only allow a usb network adapter to be connected to the guest?

I am concerned because, look at this exploit that was recently patched:

http://isc.sans.org/diary.html?storyid=6190

Reply
0 Kudos
Texiwill
Leadership
Leadership

Hello,

The player has a menu option where you can set Shared Folders to Disabled, and by default it is set to Disabled. Is that enough in terms of disabling VMware HGFS, or is it not the same thing?

Yes it is sufficient but you can also set it within the VMX file.

Do I also need to change anything in the config.ini or .vmx options in order to isolate the host as much as possible? No vmware tools will be installed in the guest.

Yes, follow the options you would set in one of the hardening guides (The book 'VMware vSphere(TM) and Virtual Infrastructure Security: Securing the Virtual Environment'[/url] contains a superset of these not currently contained within any Guide)

For the purposes of my extremely simple setup, is it enough that I physically remove from the host all network adapters and all virtual network adapters from the host AND the guest, and only allow a usb network adapter to be connected to the guest?

No, that is NOT the way to do this. USB network adapters may or may not work depending on the virtualization tool you are using. If you are using ESX/ESXi then USB within the guest will not work and YOU MUST have a service console/management appliance network connection for ESX to even boot. If you are talking about VMware Server, Workstation, Fusion, or Player then the USB network device is first given to the host operating system then bridged to the VM. If the host is compromised so it the guest. This does not change because you choose to use a USB network adapter. You could use USB Passthru within the guest on a hosted product, but I am not sure that will work either as well.

Your network security needs to be considered from the beginning even external to the VM.

I am concerned because, look at this exploit that was recently patched:

http://isc.sans.org/diary.html?storyid=6190

This applies to any of the hosted products (Server, Workstation, Fusion, and Player) and you should make sure this patch is applied and ensure that you pay attention to security patches for your virtualization products.

BTW, the patch was to vmware tools in many cases, so if you are NOT using VMware Tools you are not using paravirtualized drivers but the ones that came with your guest OS, therefore this particular vulnerability may not actually exist within your environment. Bad Drivers within a VM can cause all sorts of issues.... Most likely they will crash the VM.

As long as you have everything properly patched I do not see an issue with this. However if you really want better virtualization security, do not use a Hosted (Type 2) Virtualization Product. Use a Type 1 Hypervisor such as ESX/ESXi.


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: Securing the Virtual Environment'[/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]|Virtualization Security Round Table Podcast[/url]

--
Edward L. Haletky
vExpert XIV: 2009-2023,
VMTN Community Moderator
vSphere Upgrade Saga: https://www.astroarch.com/blogs
GitHub Repo: https://github.com/Texiwill
Reply
0 Kudos
continuum
Immortal
Immortal

If you are talking about VMware Server, Workstation, Fusion, or Player then the USB network device is first given to the host operating system then bridged to the VM.

Edward - did you ever try this yourself ? - maybe you should do that once ...

FYI USB-network devices like WLAN-sticks can be directly used from the guest - without any connection to the network-stack of the host.

With such devices it is possible to run a host that has no network capabilties at all.

___________________________________

VMX-parameters- VMware-liveCD - VM-Sickbay


________________________________________________
Do you need support with a VMFS recovery problem ? - send a message via skype "sanbarrow"
I do not support Workstation 16 at this time ...

Reply
0 Kudos
Texiwill
Leadership
Leadership

Hello,

I was thinking of normal usage for any network device. I.e. connect to the host then bridge through the hosted environment. In this case USB is no different than any network device. Then later I started to think about USB only.... SOrt of mashed two thoughts into one reply....

USB in passthru mode is still passthru with a driver running within the host as well as the VM (for windows), so there is a small footprint within the host. Could that small foot print be enough to compromise the network stack. Not sure, depends really on what the driver really does within the host. Could this reduce the exposure, certainly and seemingly by quite a bit.

But giving the CVE discussed, however you get into the VM (network or sitting at the console) there is still the issue of a bad device driver possibly causing issues and compromising both the guest and the host. In this case a VM is really no better than a physical host, you do not magically become MORE secure but virtualizing. If the guest has a network weakness whether you use a bridged network adapter or a USB network adapter will make no difference.

The interesting thing is that if you use a bridged network adapter your packets have to first pass the host's builtin firewall and then the guests builtin firewall, which could make things a little more interesting. More secure? Not sure... depends on firewall configurations more than anything. For packets destined for the VM to suddenly be picked up by the host, the bridge would need to be compromised (never seen that) or the host would have to be compromised and someone is now tied into the network stack to redirect packets.

However, bypassing the host network using a USB network device does offer less of a network footprint to attackers in a hosted environment. But if the guestOS has weaknesses it is still vulnerable.

But back to the main point of the CVE in question. If the issue still exists and one can compromise the guest (even using a USB network deivce) then regardless of having a network on the host or not, the host could possibly still be compromised. That is why the patch provided should be applied.


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: Securing the Virtual Environment'[/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]|Virtualization Security Round Table Podcast[/url]

--
Edward L. Haletky
vExpert XIV: 2009-2023,
VMTN Community Moderator
vSphere Upgrade Saga: https://www.astroarch.com/blogs
GitHub Repo: https://github.com/Texiwill
Reply
0 Kudos
UlyssesOfEpirus
Enthusiast
Enthusiast

I just had a brainwave. If inside the vmware guest you run qemu, and inside qemu you run OpenVZ, then the hacker would have to break through all three to get to the host. This decreases the probability that all break-throughs are achieved by one hacker. It's like the telnet-to-telnet anonymity tactic of old.

Reply
0 Kudos
Texiwill
Leadership
Leadership

Hello,

All you need to do is break the outside VM and the rest is history. Layering virtualization does not grant you security. Consider, that if the hacker can get to the VM he/she can get to the virtual disk being used by qemu. The hacker would never need to login to the qemu VM or access OpenVZ, the hacker would have the disk. Yes you could encrypt the disk but hey then all a hacker has to do is boot qemu to get into the VM some other way. Believe me it is possible.

The key is knowing the threats. Is Virtualization better than using a physical box? Not necessarily from a virtualization perspective. Hosted products have their own concerns. It looks like you are trying to protect against multiple things here.

1) Driver issues within a VM per the CVE you mentioned -


Solution: do not use virtualization you may not need it.

2) Network based attacks -


Solution: Secure your network, use firewalls, IPS, etc.

Virtualization does NOT magically grant you security, layering virtualization tools does not grant you security.

If you do use a virtualization product you have many benefits. Increased security is not one of them. You still need to harden your Guest OS/Hosted Operating System, secure your networks, etc.

Not only that layering virtualization performs atrociously. I have a script that runs in less than 1 minute on a physical box/single VM. With layered virtualization it takes 10+ minutes to run. Huge performance hit.


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: Securing the Virtual Environment'[/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]|Virtualization Security Round Table Podcast[/url]

--
Edward L. Haletky
vExpert XIV: 2009-2023,
VMTN Community Moderator
vSphere Upgrade Saga: https://www.astroarch.com/blogs
GitHub Repo: https://github.com/Texiwill
Reply
0 Kudos
UlyssesOfEpirus
Enthusiast
Enthusiast

"Virtualization does NOT magically grant you security, layering virtualization tools does not grant you security."

I never said layered virtualization grants me security. Security is not something that is either "granted" or "not granted", but all shades of gray exist. Say black is no security at all, and white is the fabled perfect security. I am proposing that layered virtualization is a lighter shade of gray than plain vmware. If you want a metric for it, pay a dozen average hackers to penetrate plain vmware, and then pay them to penetrate layered virtualization. The number of hackers succeeding in each setup, is a practical metric of its security. Do you believe with layered virtualization the host will be penetrated by the same number of people as plain vmware?

Reply
0 Kudos
continuum
Immortal
Immortal

I would think that if some bad guy detects a machine which runs "VM in a VM stuff " he drops interest - he probably thinks this must be some experimental setup - nothing of worth behind it ....

___________________________________

VMX-parameters- VMware-liveCD - VM-Sickbay


________________________________________________
Do you need support with a VMFS recovery problem ? - send a message via skype "sanbarrow"
I do not support Workstation 16 at this time ...

Reply
0 Kudos
Texiwill
Leadership
Leadership

Hello,

I would not think this way, nor would my penetration testing friends. Virtualization within Virtualization (VinV) is also VERY intriguing from a forensics perspective as you wonder why VinV is actually in use. Is it to put up a personal VM on top of corporate assets? Perhaps this is a VM used for industrial espionage or social networking only. Virtualization within Physical (VinP) is also very interesting from a forensics perspective for much the same reasons). Eventual VinV maybe as common place as VinP with the advent of cloud and faster processors. This forensics discussion aside....

The problem with layered virtualization is that you only have to defeat the layer containing the other layers to also defeat every other layer after it. For example:

VMware Server running a VM running qemu running OpenVZ.

If a hacker can break the VM in this situation. A hacker now has access to the qemu virtual disk which is running OpenVZ. If the hacker can mount that virtual disk or download it for later work and do stuff with it, does the hacker need to further break qemu or OpenVZ?

If you are talking about network based attacks for example, all packets for OpenVZ will be seen by qemu which will be seen within the VM assuming you are using your USB based network adapter. In this case, if the outer VM is breakable then all packets are sniffable by this VM. Granted, in some cases, the hacker may not even need access to the VM to see the packets running to the USB device.

Performance being what it is for VinV is what inside the inner VM all that important? Could be, may not be, but do not count on it not being attacked just because you are trying to obfuscate things.


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: Securing the Virtual Environment'[/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]|Virtualization Security Round Table Podcast[/url]

--
Edward L. Haletky
vExpert XIV: 2009-2023,
VMTN Community Moderator
vSphere Upgrade Saga: https://www.astroarch.com/blogs
GitHub Repo: https://github.com/Texiwill
Reply
0 Kudos
UlyssesOfEpirus
Enthusiast
Enthusiast

"VMware Server running a VM running qemu running OpenVZ.

If a hacker can break the VM in this situation.

if the outer VM is breakable"

But you haven't said why the outer VM is breakable from malware running inside the inner VM. Are you thinking in terms of bridged networking? It's a usb adsl modem that I want to connect to the innermost VM, the other VMs have no networking at all. Why is it easier to break into the outer VM first from malware running in the innermost VM?

Reply
0 Kudos
Texiwill
Leadership
Leadership

Hello,

But you haven't said why the outer VM is breakable from malware running inside the inner VM. Are you thinking in terms of bridged networking?

Well I did not quite state this, I said it looks like you are trying to protect against the HOST being attacked from the VM and at the same time limit networking issues.

The outer host is not necessarily breakable from within the VM. THis is escaping the VM and any such attacks, of which I know of three, have been patched by the vendors.

It's a usb adsl modem that I want to connect to the innermost VM, the other VMs have no networking at all. Why is it easier to break into the outer VM first from malware running in the innermost VM?

Where ever the ADSL modem is attached is where you have your network weakness. If for example you have:

HOST -> VM -> QEMU -> OpenVZ

And the Modem is at the 'VM' then if the VM is attacked over the network successfully then the hacker can see everything contained within the VM such as the QEMU disk and the OpenVZ containers plus all network traffic.

If the QEMU is broken the hacker can see OpenVZ.

If you attach the USB device to a VM on windows hosted environment, windows gets a driver installed. Is this driver trustworthy? I am not sure so there could be a risk that needs addressing.


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: Securing the Virtual Environment'[/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]|Virtualization Security Round Table Podcast[/url]

--
Edward L. Haletky
vExpert XIV: 2009-2023,
VMTN Community Moderator
vSphere Upgrade Saga: https://www.astroarch.com/blogs
GitHub Repo: https://github.com/Texiwill
Reply
0 Kudos
UlyssesOfEpirus
Enthusiast
Enthusiast

Looking at the device manager of the host, I see that the usb modem device has no driver, I am supposed to install a driver off the cd. When the usb modem is connected to the VM, the device completely disappears from the device manager of the host.

So there must be something else that facilitates the communication from the physical usb port to the virtual usb port. Would that be the vmplayer.exe executable?

Reply
0 Kudos
UlyssesOfEpirus
Enthusiast
Enthusiast

Actually, maybe there's no communication at all, the VM is directly writing to and reading from the hardware with machine code instructions.

Reply
0 Kudos
Texiwill
Leadership
Leadership

Hello,

The driver within the VM talks to the USB Passthru device presented to the VM through the virtualization layer.That Pass Thru device does have a small bit of code within the host. Usually within the hypervisor but sometimes within the host as well. I know when I pass a usb device to a VM from the host it installs a driver of some sort within the host.


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: Securing the Virtual Environment'[/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]|Virtualization Security Round Table Podcast[/url]

--
Edward L. Haletky
vExpert XIV: 2009-2023,
VMTN Community Moderator
vSphere Upgrade Saga: https://www.astroarch.com/blogs
GitHub Repo: https://github.com/Texiwill
Reply
0 Kudos
echiu
Contributor
Contributor

Fixing HyTrust search in VMware communities.

Reply
0 Kudos