You might be aware of the 3 critical security issues that VMware has published and fixed a couple of days ago in VMSA-2015-0007. The information provided in the security advisory regarding the first issue, CVE-2015-5177 (ESXi OpenSLP Remote Code Execution), are:

VMware ESXi contains a double free flaw in OpenSLP's SLPDProcessMessage() function. Exploitation of this issue may allow an unauthenticated attacker to remotely execute code on the ESXi host. Relevant Releases

VMware ESXi 5.5 without patch ESXi550-201509101

VMware ESXi 5.1 without patch ESXi510-201510101

VMware ESXi 5.0 without patch ESXi500-201510101

In this post I am trying to give a better understanding of the vulnerability and its consequences. Please note that the information in this post are my personal opinions. I cannot guarantee that these information are accurate. The main fact is that VMware has published a fix and you should install the patch to be on the safe side. In the real world, you might have something like a "change process" where you can't rollout the patch for hundreds of systems immediately. Or you have a single ESXi that you don't want to reboot at the moment. In this situation, this post tries to help...

What it the Risk?

With this vulnerability an unauthenticated attacker is potentially able to execute code remotely. This kind of flaw is probably the worst. The good point is that hopefully all ESXi hosts are running in dedicated management networks with access control. If you follow VMwares security best practises, the ESXi management network is only accessible for known administrators. I am aware of the "Most attacks come from the inside" myth and this does not fix the issue, but it reduces the access vector drastically (Imagine the same issue in an internet facing application like a Webserver). Additionally, there is currently no publicly known exploit available for this issue.

What is a "Doble Free Flaw"?

A double free flaw is programming error where a part of memory that was previously allocated is freed more than once. Unlike to a buffer overflow, where the memory chunck was never valid, a multiple free occurs as a result of a valid instruction being executed in a invalid manner.

It's a flaw in OpenSLP which is an open source implementation of the Service Location Protocol.

What is SLP?

Service Location Protocol (SLP) is a standard protocol that provides a framework to allow networking applications to discover the existence, location, and configuration of networked services in networks.

If you do not know the URL to access the WBEM service of the CIMOM on the ESXi machine, or if you do not know the namespace, use SLP to discover the service and the namespace before your client makes a connection to the CIMOM.

How is it relevant in ESXi?

The SLP daemon is running on each ESXi Host listening on Port 427 TCP/UDP. According to KB1012382 it is required for the communication between the vSphere Client and the ESXi.

You can verify slpd from command line:

~# esxcli network ip connection list |grep 427 tcp 0 0 192.168.0.25:427 0.0.0.0:0 LISTEN 34139 newreno tcp 0 0 127.0.0.1:427 0.0.0.0:0 LISTEN 34139 newreno udp 0 0 :::427 :::0 34139 udp 0 0 0.0.0.0:427 0.0.0.0:0 34139 ~# /etc/init.d/slpd status slpd is running

You can monitor incoming packets with tcpdump-uw:

~# tcpdump-uw -n -s0 port 427

You can see the service in Firewall configuration (ESXi > Configuration > Software > Security Profile):



What can I do with SLP?

Do give you an idea what slp is good for, here are some examples how you can query the SLP service from an external Linux host:

#Install slp-tools (Debian) root@pi1:~# apt-get install slp-tools

#Find a Server using Unicast root@pi1:~# slptool unicastfindsrvs esx6.virten.lab service:VMwareInfrastructure service:VMwareInfrastructure://esx6.virten.lab,65535

#Find Server Attributes using Unicast root@pi1:~# slptool unicastfindattrs esx6.virten.lab service:VMwareInfrastructure (product="VMware ESXi 6.0.0 build-2494585"),(hardwareUuid="C9120900-9149-11E4-B276-B8AEED750868")

#Find Servers using Multicast root@pi1:~# slptool findsrvs service:VMwareInfrastructure service:VMwareInfrastructure://esx1.virten.lab,65535 service:VMwareInfrastructure://esx6.virten.lab,65535

We have a strict change process and I want to Install the Security Patch only. Is that possible?

Yes. You can install a single patch with the Update Manager, or from the command line:

Fix CVE-2015-5177 with Update Manager:

Open Update Manager Navigate to Patch Repository Use the Search field to find the patch (eg. ESXi550-201509101 for ESXi 5.5) Click "Add to baseline..." and add the patch to your Baseline (I assume that you already have a fixed baseline with compliant Hosts)

Remediate the Update

Fix CVE-2015-5177 from Command Line:

You might be aware that each update bundle contains separate image profiles for "security only" fixes and "all" fixes. (This is why some bundles are ~660MB and others only ~330MB. Some updates contain security patches only, so their size is 330MB). To install the security only patch for ESXi 5.5:

Download the update depot (update-from-esxi5.5-5.5_update03.zip) Copy it to a datastore that the ESXi can access Open a SSH connection to the ESXi host (Put the host into maintenance mode) Update the ESXi host to the "security only profile" (the s behind the patch number indicates the security profile) with the following command:esxcli software profile update -d <bundle zip file> -p <profile_name> Example:

esxcli software profile update -d /vmfs/volumes/[Datastore]/update-from-esxi5.5-5.5_update03.zip -p ESXi-5.5.0-20150901001s-standard Reboot

Can I stop or block SLP to mitigate the Problem?

From my understanding the issue is relevant to the SLPD running on ESXi. I don't have an official statement about dependencies from that service or whether it helps to stop it, but here are some findings:

I've used tcpdump to see how often the service is queried during "administration tasks". There were no packets.

I've stopped the service and didn't notice any issues

I've blocked the port in the ESXi firewall and didn't notice any issues

When I need remote access an ESXi host I typically allow/forward 22 (ssh) 443 (https) and 902

So...probably, it's possible to mitigate the issue by stopping or blocking SLP (No guarantee that it will work or mitigate the issue at all!). If you want to block it, use the vSphere Client and navigate to ESXi > Configuration > Software > Security Profile -> Properties and remove the Checkbox from the CIM SLP Service: