On April 19th, VMware released a series of patches for ESX 5.5 and ESX 5.5 Update 1 to re-mediate the CVE dubbed “Heartbleed” (CVE-2014-0076 and CVE-2014-0160).

VMware also recently announced that there was an issue in the newest version of ESXi 5.5 (Update 1 and later), which can cause difficulties communicating with NFS storage. This NFS issue is still being investigated, and customers are encouraged to subscribe to KB article: Intermittent NFS APDs on ESXi 5.5 U1 (2076392) for updates.

Due to the confluence of these two unrelated issues, you might find yourself trying to patch ESXi to protect yourself from the Heartbleed vulnerability, while at the same time trying to avoid installing ESXi 5.5 Update 1.

Here is the information from the VMware Knowledge Base on the topic:

The note at the bottom is the key. Stated simply, if you are…

• Using NFS storage
• Concerned about patching to Update 1 due to change control
• Not already running ESXi 5.5 Update 1 (build-1623387)

… then you should patch your install for the Heartbleed issue and at the same time stay at ESX 5.5 by applying Patch Release ESXi550-201404020, and not ESXi550-201404001.

An Explanation of Patch Release Codes

To better understand the Patching process in a VMware environment, it is valuable to understand the codes which are used in VMware Patch Releases.

When VMware releases a patch, or a series of patches, they are bundled together in what is known as a Patch Release. A Patch Release will have a coded name which is formed using the following structure. I have added braces to demonstrate the different sections better in each example.

[PRODUCT]-[YEAR][MONTH][THREE DIGIT RELEASE NUMBER]

For example, the patch release for ESXi 5.5 that was released in January 2013 would be coded like this (without the explanatory braces):

[ESXi550]-[2013]-[01][001]

As part of a Patch Release, there will be at least one Patch. Each Patch is given a Patch (or Bulletin) ID. Patch IDs are similarly structured to Patch Release codes, but also have a two letter suffix. For Security Bulletins, the prefix will be SG. For Bug Fix Bulletins, the prefix will be BG.

For example, the two Patch IDs which were released to patch Heartbleed are:

[ESXi550]-[2014][04][401]-[SG]
[ESXi550]-[2014][04][420]-[SG]

Note that the only difference in the Patch IDs here is in the three digit release number (401 vs 420).

Patching with VMware Update Manager

There are a number of methods for patching ESXi hosts, and the most commonly used is VMware Update Manager (VUM). VUM will present a pair of Dynamic Baselines which will be automatically updated when patches are available. The danger in this case is that VUM may show you both the Pre-Update 1 patch, as well as the Post-Update 1 patch. If you are not careful as to which patches you apply, you might accidentally end up patching your host to Post-Update 1.

Here are the patches which were released on April 19th, as seen in VUM. The Update 1 patch is highlighted in red, while the Pre-Update 1 patch is marked in green.

Note: VMware also released two other ESXi 5.5 patches on April 19th, as part of Patch Release but these are not related to the Heartbleed vulnerability in any fashion. (ESXi550-201404402-BG, and ESXi550-201404403-BG).

Creating a Fixed Baseline

Patching a host using ESXi550-201404420-SG (Pre-Update 1), while avoiding ESXi550-201404401-SG (Post-Update 1) requires the use of a Fixed Baseline in Update Manager.

1. Start in the Update Manager Admin view.
2. Select the Baselines and Groups tab.
3. Click Create… in the Baselines column.
   
4. Give the new Baseline a descriptive Name (and optionally a Description).
   
5. Click Next.
6. For Baseline type, select Fixed.
   
7. Use the Search feature to find the only Patch we want to apply. You will need to select the Patch ID option from the dropdown menu to ensure the search scans for the appropriate column.
   
8. Enter the Patch ID into the search field: ESXi550-201404420-SG and click Enter to search.
9. Select the Patch which shows up in the filtered list, and click the Down Arrow to move it into the selected Baselines.
   
10. Click Next and confirm that the Patch ESXi550-201404420-SG is the only one selected.
    
11. Click Finish.

The Baseline is now created and available for use.

Remediating a Host using the Fixed Baseline

Once the Fixed Baseline has been created, we can use it to Scan and Remediate an ESXi host.

1. Select the host you wish to patch, and place it into Maintenance Mode.
2. Click the Update Manager tab.
3. Make sure that there are no Dynamic Baselines attached to the host you wish to patch. Detach any baselines which are currently attached:
   Critical Host Patches (Predefined)
   Non-Critical Host Patches (Predefined)
   Any other Custom Baselines which you have created
4. Click the Attach link.
   
5. Select the newly created Baseline and click Attach.
   
6. Click the Scan link and make sure Patches and Extensions is selected. Click Scan again.
   
7. When you are ready to patch the host, select Remediate.
8. Complete the Remediation wizard.

Once the host is patched, it will reboot automatically.

Patching an ESXi host manually via the command line

Another option to patch an ESXi host is to use the esxcli command line tool. The patch files required are the same. For more information on how to proceed with this route, refer to the vSphere 5.5 Documentation under the heading Update a Host with Individual VIBs.

References

• VMware Security Advisory VMSA-2014-0004.7
• Resolving OpenSSL Heartbleed for ESXi 5.5 – CVE-2014-0160 (2076665)
• VMware ESXi 5.5, Patch Release ESXi550-201404001 (2076120)
• Intermittent NFS APDs on ESXi 5.5 U1 (2076392)

Author: Andrew Lytle
As a member of the VMware Mission Critical Support Team, Andrew Lytle is a Senior Support Engineer who is specializes in vCenter and ESXi related support.