Virtualization Pro

Feb 5 2009   7:59PM GMT

New VMware ESX v3.5 U3 vulnerabilities

Texiwill Edward Haletky Profile: Texiwill

There is a new vulnerability in VMware ESX v3.5 U3 with all the patches that has just come to light. VMware has been made aware of this issue, and will fix it sometime in the near future. This bug relates to world writable directories on the VMware ESX service console.

This is not a huge issue as long as your VMware ESX service console is properly protected, but you may want to be concerned if it is not. The vulnerability allows any one who can access the VMware ESX host to write anything to these directories and could cause a disk to fill up or something worse to happen.  The remediation is quite simple.

chmod 755 /var/lib/pegasus /var/lib/pegasus/trace

This is a simple oversight that could lead to something possibly dangerous. However it is also easily made right. This is one of the reasons that is you are using a security assessment script that you run after every patch or update.

The other issue is more a historical item that could lead to a possible security issue if a malicious user does have access to the service console once more. This is the ability to run code as root possibly within the hypervisor using the vmkload_app and vmware-vmx commands. These programs are set up with their setuid bits which allows a normal user to run these as the super user. The reason these are set up this way is more an issue of history.

In VMware ESX 2.5.x days, it was possible for a normal user to run VMs. With VMware ESX v3.x this functionality was dropped from any of the management tools, yet the capability was left in. The solution is to remove the setuid bits so that these commands can only be run as the root user, which is their normal method of operation.

chmod u-s /usr/sbin/vmware-authd /usr/lib/vmware/{bin,bin-debug}/{vmkload_app,vmware-vmx}

It is interesting that while the DISA UNIX STIG and CISecurity CIS-CAT for RHEL found these issues, the TripWire ConfigCheck tool did not. This inconsistency has been reported to Tripwire as well, and they will work with VMware for a possible VMware Hardening Guide modification. TripWire ConfigCheck goes so far as to warn you that these files have had their setuid bits removed, when it should check to see if they are missing. It is a contradiction.

Making these changes will add to your security stance but not harden your system 100%. In my case, I never trust just one hardening guide as they often over look things that the others do not. I try to make my systems pass all the guidelines available and if there are inconsistencies between them, I document those decisions as well. Note that there are several inconsistencies in each guide.

These slight changes are also reasons you want to redo security assessments after you patch or update your VMware ESX hosts!

 Comment on this Post

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when other members comment.

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

Share this item with your network: