Shellshock Vulnerability

So last week it was reported that a serious vulnerability was discovered in Bash (Bourne-Again SHell) which is pretty much core to a lot of Linux/Unix OSes – including Apple’s MacOS. The bug, dubbed Shellshock, is supposed to be more serious than the previous OpenSSL Heartbleed vulnerability that was discovered earlier this year. It allows hackers to remotely take control of any system running Bash!

VMware have now released a KB that explains which hypervisors are affected by Shellshock.

http://kb.vmware.com/kb/2090740

Thankfully only the really old versions of vSphere ESX are affected…..

vSphere ESXi/ESX Hypervisor

  • ESXi 4.0, 4.1, 5.0, 5.1, and 5.5 are not affected because these versions use the Ash shell (through busybox), which is not affected by the vulnerability reported for the Bash shell.
  • ESX 4.0 and 4.1 have a vulnerable version of the Bash shell.

Given how serious this vulnerability is, VMware are actually going to roll out a security patch for ESX 4.0 and 4.1 even though they are out of general support.

It is also worth noting that all VMware products currently shipped as a virtual appliance (usually a SLES VM) have the affected version of Bash installed. These virtual appliances will be updated in the near future.

I would recommend all VMware customers to keep an eye out for updates that will address the Shellshock vulnerability!

Advertisements

Upgrading to SRM 5.8 and vSphere Replication Appliance 5.8

There were new versions released earlier this month for a number of VMware products, and one of the things I like to do is keep my demo environment up to date! =)

Upon upgrading SRM from 5.5 to 5.8 and vRA from 5.5 to 5.8 (I’m using vSphere replication with SRM in my demo environment), I noticed that the usual process of upgrading the vRA from the admin page doesn’t work if you point it at the online repository!
srm2

From the Release Notes, it turns out that the downloadable ISO image is the only means of upgrading from vRA 5.5.x or 5.6 to 5.8!
You’re not able to use VUM or the VAMI (Virtual Appliance Management Interface – the vRA admin page) to do the upgrade! =(

So what you have to do is download the full vRA ISO image, mount the ISO to the vRA and then change the update repository to use CD-ROM updates:
srm3
srm4

 

NOTE: Ensure you follow the VMware Upgrade method to the DOT…….!!
The first update went wrong as I mounted the ISO file from my desktop to the vRA via the vSphere Client, and when it updated and rebooted it lost the connection to vCenter and I didn’t have the option to re-register the vRA…. >_<”
I pretty much had to delete the vRA and install a brand new one and I’m still none the wiser as to what went wrong during the upgrade!!

vRA Upgrade Procedure

  1. Download the vRA 5.8 ISO image and copy the ISO file to a datastore that is accessible from the vCenter Server where your vRA is currently deployed.
  2. In Web Client, right-click the vSphere Replication virtual machine and select Edit Settings.
  3. In Virtual Hardware, select CD/DVD Drive > Datastore ISO File.
  4. Navigate to the ISO image in the datastore.
  5. For File Type, select ISO Image and click OK.
  6. Check the box to connect at power on and follow the prompts to add the CD/DVD Drive to the vSphere Replication virtual machine.
  7. Restart the vSphere Replication virtual machine.
  8. In a Web browser, log in to the virtual appliance management interface (VAMI).
    If you are updating vSphere Replication 5.1+, go to https://vr_appliance_address:5480.
  9. Click the Update tab.
  10. Click Settings and select Use CDROM Updates, then click Save Settings.
  11. Click Status and click Check Updates.
    The appliance version appears in the list of available updates.
  12. Click Install Updates and click OK.
  13. After the updates install, click the System tab and click Reboot to complete the upgrade.
  14. Log out of the vSphere Web Client, clear the browser cache, and log in again to see the upgraded appliance.

 

Once you’ve upgraded the vRA to 5.8, you can now go ahead and upgrade your SRM server to 5.8…… simply run the SRM installer and follow the installation wizard!

Note: if you didn’t upgrade the vRA before trying to upgrade the SRM server, when the installer prompts to connect to the vCenter Server, you will get the following error:
srm1

 

BIG WARNING HERE: As soon as you upgrade your SRM to 5.8, you can only manage it via the Web Client…..!!!
And it is completely re-written……. took me a while to work out where all the settings were located!
Same with vRA 5.8, you can’t set replication within the old vSphere client.

Note: I still have no idea where the SRM alarms are set……. ¬_¬”

 

PS: One of the cool things about vRA 5.8 is the ability to replicated to the cloud! =)

 

Edit (15/10/14) – The alarms for SRM can be found under the alarms of the vCenter Server that you connected the SRM server to:
In web-client, select vCenter the vCenter Server and under the “Manage” tab, you will find a tab called “Alarm Definitions”. This is where all the SRM alarms are located. =)

srm alarms

vSphere and vCenter Server 5.5 update 2 released

…. so instead of giving us all vSphere/vCenter Server 6.0, we’re treated to another update of 5.5…… =(

https://www.vmware.com/support/vsphere5/doc/vsphere-vcenter-server-55u2-release-notes.html
https://www.vmware.com/support/vsphere5/doc/vsphere-esxi-55u2-release-notes.html

Anyways, the new update now supports hosts with up to 6TB of RAM…. yes, that’s 6 terabytes!!! (I’ll be interested to find out if any of my clients will take advantage of this!!)

vCenter Server can now also support Oracle 12c, Microsoft SQL Server 2012 SP1 and Microsoft SQL Server 2014.

There’s also a new ‘container’ within the Web client home page that allows you to integrate with vCHS (or vCloud Air as it’s now called).

The other bit of big news if that the vSphere client no longer supports Windows XP or Vista…. which means those of you still running those archaic operating systems need to update!

All-in-all, not really much to write home about……. Come on VMware, release version 6.0 to the world!!! =)

vCenter Operations Manager – SSL Certificate issues

So during a recent deployment of vCenter Operations Manager (5.8.2) at a customer site I encountered the following error whilst trying to pair the vCOPs vApp to their vCenter Server.

vcops ssl cert

“Unable to get vCenter Server certificate chain”

This was the first time I had encountered this issue deploying vCOPs, fortunately given how much exposure I got to SSL certifications during a previous project I knew it could be down to one of 2 things….. either the SSL certificate had expired, or that it was not generated with the correct parameters.

Note: Quickest way to look at a vCenter Server’s SSL certificate is to just open a browser and point it at the vCenter’s IP address, then view the certificate…..
vcops ssl 1 vcops ssl 2
(Left – IE, Right – Chrome)

or if it’s a Windows deployment of vCenter 4.1 or later, you can find the certificate here: C:\ProgramData\VMware\VMware VirtualCenter\SSL\rui.crt (Note that c:\ProgramData is a hidden folder!).

 

It seemed that the SSL certificate was valid (expiry date was 2022), however I noticed that the public key certificate was weak as the key length was only 512 bits!!
What had happened was a previous partner had upgraded them from VI3.5 to vSphere 4.0 to vSphere 5.0 and had forgotten to re-generate the SSL certificates!
Prior to vCenter Server 4.1, by default VMware self-signed their SSL certificates with a public key length of 512 bits! So when they upgraded they kept the same SSL certificates.

Post vCenter Server 4.1, if you installed from scratch the public key length is set to RSA 2048 bits by default.
vcops ssl 3
So because the public key length was only 512 bits, vCOPs could not authenticate the vCenter Servers’ certificate (I believe it has to be a minimum of 1024 bits)!
More info from VMware’s KB here: http://kb.vmware.com/kb/2037082 and Microsoft’s KB here: http://support.microsoft.com/kb/2661254

 

As it was a production environment and they couldn’t afford to regenerate their SSL certificates, I had to ‘inject’ the vCenter Server certificate into the vCOPs VMs keystores as follows:

  1. Copy the rui.crt file (the SSL certificate) on the vCenter Server into the tmp drive of the vCOPs UI VM. (This can be easily achieved using WinSCP).
  2. Login to the console of the UI VM as root.
  3. Change to the directory where the certificate keystore is located: /usr/lib/vmware-vcops/user/conf
  4. Issue this command to add the vCenter Server certificate to the certificate store: keytool -importcert -file /tmp/rui.crt -alias https://<VC FQDN or IP>/sdk -keystore truststore -storepass oxygen
  5. Issue this command to verify that the certificate is in the certificate store: keytool -list -keystore truststore -storepass oxygen
  6. Issue this command to copy the truststore file from the UI virtual machine and paste it to the Analytics virtual machine: scp truststore secondvm-external:/usr/lib/vmware-vcops/user/conf/
  7. Restart all services with the su – admin -c “vcops-admin restart” command, or reboot the vApp from the vCOPs admin page.

Once the SSL certificate was injected into the vCOPs VMs keystore it was plain sailing and we could continue with the setup wizard.

 

Ideally if you still have weak certificates in your environment, you should really be replacing them by generating new SSL certs! =)