All Versions of VMware vSphere Client download link

vSphere Client Version	Installer File Name	Download  Link (Click on the Image to Download)
VMware vSphere Client v4.1 Update 1	VMware-viclient-all-4.1.0-345043.exe
VMware vSphere Client v4.1 Update 2	VMware-viclient-all-4.1.0-491557.exe
VMware vSphere Client v4.1 Update 3	VMware-viclient-all-4.1.0-799345.exe
VMware vSphere Client v5.0	VMware-viclient-all-5.0.0-455964.exe
VMware vSphere Client v5.0 Update 1	VMware-viclient-all-5.0.0-623373.exe
VMware vSphere Client v5.0 Update 2	VMware-viclient-all-5.0.0-913577.exe
VMware vSphere Client v5.0 Update 3	VMware-viclient-all-5.0.0-1300600.exe
VMware vSphere Client v5.1	VMware-viclient-all-5.1.0-786111.exe
VMware vSphere Client 5.1.0a	VMware-viclient-all-5.1.0-860230.exe
VMware vSphere Client 5.1.0b	VMware-viclient-all-5.1.0-941893.exe
VMware vSphere Client 5.1 Update 1	VMware-viclient-all-5.1.0-1064113.exe
VMware vSphere Client 5.1 Update 1b	VMware-viclient-all-5.1.0-1235233.exe
VMware vSphere Client 5.1 Update 2	VMware-viclient-all-5.1.0-11471691.exe
VMware vSphere Client 5.5	VMware-viclient-all-5.5.0-1281650.exe
VMware vSphere Client 5.5 Update 1	VMware-viclient-all-5.5.0-1618071.exe
VMware vSphere Client 5.5 Update 2	VMware-viclient-all-5.5.0-1993072.exe

Manually Update Bash to Patch Shellshock Bug on RHEL Based Linux Systems

Step 1: Back up your existing Bash binary

Find out where your existing bash binary is located on your system with:

PowerShell

which bash

1	which bash

You’ll get a response like:

PowerShell

/bin/bash

1

/bin/bash

Backup that file with:

PowerShell

sudo cp /bin/bash /bin/bash.old

1	sudo cp /bin/bash /bin/bash.old

Step 2: Determine which version of Bash you’re running

Now you’ll need to determining which version of bash your system is running. If you’re running Fedora 12, for example, it’s probably version 4.0. You can find out your version with:

PowerShell

bash --version

1	bash --version

which will spit out a version number that looks something like this:

PowerShell

GNU bash, version 4.0.1(1)-release (i686-redhat-linux-gnu)

1	GNU bash, version 4.0.1(1)-release (i686-redhat-linux-gnu)

The first two numbers in 4.0.1 means you’re running Bash version 4.0. Remember your version number, as you’ll need that later. The third number in 4.0.1 can be a bit confusing, because it will mean something different based on where it came from. In this example, because “redhat” appears in the description, the third number is the build number in the RedHat repositories. However, if your output looked like this:

PowerShell

GNU bash, version 4.0.42(1)-release (i686-pc-linux-gnu)

1	GNU bash, version 4.0.42(1)-release (i686-pc-linux-gnu)

the fact that it says only “pc” in that part of the description means Bash was manually compiled on your system (probably by you) and so in that case, the third number refers to the patch level of Bash version 4.0. Your goal at the end of this post is to have Bash report a version that looks like this, with the highest possible patch level. Do not confuse the Bash version with the patch level! Your goal during this fix should be to keep your version number the same, but increase your patch level to the highest possible number. A higher version number doesn’t necessarily mean you’re protected. Being patched to the highest patch level, regardless of your version number, is what you care about in this case. Finally, as you move through the following steps, resist the urge to move to a newer version number of Bash versions… as you’ll probably end up causing more problems than you’ll fix. Patching your current version of Bash is the best option to ensure things keep working on your system.

Step 3: Set up your fix environment

Whenever I’m working with source code on a Linux box, I like to keep everything in the /usr/local/src directory. So create a new subdirectory for fixing bash, and then jump into that directory, with:

PowerShell

mkdir /usr/local/src/bashfix cd /usr/local/src/bashfix

1 2	mkdir /usr/local/src/bashfix cd /usr/local/src/bashfix

You should also make sure you have a few required packages that will come in handy later (like patch, byacc, bison, autoconf, etc.) do:

PowerShell

sudo yum install patch byacc textinfo bison autoconf gettext ncurses-devel

1	sudo yum install patch byacc textinfo bison autoconf gettext ncurses-devel

Step 4: Download the Bash source

Locate the matching source code for the version of Bash you’re already running on the GNU.org FTP server. Since my test system was using 4.0, that’s what I’ll download in this example, but you should obviously download the one that’s appropriate for your system. Again, resist the urge to upgrade to a newer version (such as 4.1, 4.2, or 4.3 in this example). This can potentially create serious problems. Just stick with what you’ve already got for now. Download and extract the appropriate Bash source code into your fix directory with:

PowerShell

wget https://ftp.gnu.org/pub/gnu/bash/bash-4.0.tar.gz tar zxvf bash-4.0.tar.gz

1 2	wget https://ftp.gnu.org/pub/gnu/bash/bash-4.0.tar.gz tar zxvf bash-4.0.tar.gz

You should now have a new sub-directory containing the bash source. In this example, that directory is /usr/local/src/bashfix/bash-4.0. Move yourself into the newly extracted bash source code directory with:

PowerShell

cd bash-4.0

1	cd bash-4.0

Step 5: Download and Apply the Patches

If you check the GNU.org FTP server where you downloaded the source code, you’ll also see a few sub-directories for each major version that contain all the patches for that version. Different versions of Bash have a different number of patches. In our example, the patches are located in https://ftp.gnu.org/pub/gnu/bash/bash-4.0-patches/. Checking that directory (as of  Oct 1, 2014) shows a total of 42 patches for version 4.0, from  bash40-001 to bash40-042. Your first option is to download the first patch, apply it to the source code, then download the second patch, apply it to the source code, and so on. Don’t do this just yet, because I’m going to show you a faster way to do it. But you should at least understand what’s happening before you automate it. The command you’d use to download the first patch and apply it in a single step would be (again, don’t do this… it’s just for illustration):

PowerShell

curl https://ftp.gnu.org/pub/gnu/bash/bash-4.0-patches/bash40-001 | patch -p0

1	curl https://ftp.gnu.org/pub/gnu/bash/bash-4.0-patches/bash40-001 | patch -p0

That command uses curl to download the patch 001, then pipes the downloaded patch into the patch command, which patches the source code in that directory (you can check the patch man page for more details, if you want). If you did this manually, you’d have to repeat this command for each individual patch file, changing the 001 to 002, and then again changing it to 003, and so on until you reached the final patch. But my buddy Steve Cook helped me write a script (I stored it on GitHub as a Gist) that will automate all the patching for you. You just need to tell it the bash version you’re patching, and the total number of patches available for that version. Check it out: https://gist.github.com/stevejenkins/3d64d3543060c1bcac92 Make sure you’re in the Bash source code directory you extracted, then download the “raw” version of the  bash-multipatch.sh script we wrote with:

PowerShell

wget https://gist.githubusercontent.com/stevejenkins/3d64d3543060c1bcac92/raw/1ab592f5c8b584e9a0debf8e2ccbcac50cbf6e73/bash-multipatch.sh

1	wget https://gist.githubusercontent.com/stevejenkins/3d64d3543060c1bcac92/raw/1ab592f5c8b584e9a0debf8e2ccbcac50cbf6e73/bash-multipatch.sh

Edit the file with your favorite text editor and set the version, nodotversion, and lastpatch variables in the script to the appropriate values for your situation (the nodotversion is simply the version number of bash without a dot in the middle). In our example, the variables are 4.0 (because we’re using Bash 4.0), 40 (same as the version without the dot), and 42 (since there are 42 total patches available for this version of Bash). Depending on your version, the number of patches will be different.
I do my best to stay on top of this issue, but It’s possible that even more patches are available in the patches directory before I’ve had a chance to update this article. You should always set the lastpatch variable in the script to the last patch you see in the directory to ensure the highest level of vulnerability protection. Save your edited file, then make it executable with:

PowerShell

chmod 755 bash-multipatch.sh

1	chmod 755 bash-multipatch.sh

Now run it inside the Bash source code directory with:

PowerShell

./bash-multipatch.sh

1	./bash-multipatch.sh

Depending on your connection speed, it shouldn’t take very long to download all the patches and apply them. You’ll see each download and patch happen on your screen as the script runs. Keep an eye out for any error messages. The very last one should look something like this:

PowerShell

https://ftp.gnu.org/pub/gnu/bash/bash-4.0-patches/bash40-042 % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 101 4056 101 4056 0 0 10947 0 --:--:-- --:--:-- --:--:-- 54810 patching file parse.y patching file patchlevel.h

1 2 3 4 5 6

https://ftp.gnu.org/pub/gnu/bash/bash-4.0-patches/bash40-042 % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 101 4056 101 4056 0 0 10947 0 --:--:-- --:--:-- --:--:-- 54810 patching file parse.y patching file patchlevel.h

You can verify your source is patched to the level you want with:

PowerShell

cat patchlevel.h

1	cat patchlevel.h

If you look near the end of that file and see #define PATCHLEVEL followed by the last patch available for your version, then your source is patched to the highest level and should address the Shellshock Bug. Now you’re ready to build the patched version of your bash binary.

Step 6: Build and Install your Patched Bash Binary

It’s best if the “configure” and “make” steps in this section are performed as a regular, non-root user. However, on particularly older systems, if you’re getting errors other than missing dependencies when running “configure,” you may just have to do them as root.
In the source code directory, do:

PowerShell

./configure

1	./configure

You’ll see your system check to make sure everything is ready for your build. If you don’t see any errors, go ahead and make the new binary with:

PowerShell

make

1

make

Then test with:

PowerShell

make test

1

make test

When everything is done you should be able to do this command:

PowerShell

ls -la bash

1	ls -la bash

And you’ll see a newly build Bash binary with a timestamp of just a few seconds ago, like this:

PowerShell

-rwxrwxr-x 1 root root 2273014 2014-09-28 08:37 bash

1	-rwxrwxr-x 1 root root 2273014 2014-09-28 08:37 bash

Now copy the new binary to where your old bash binary was located in Step 1 (which is almost certainly /bin/bash) with:

PowerShell

sudo cp -f bash /bin/bash

1	sudo cp -f bash /bin/bash

Step 7: Test Your Fix

Now that you’ve manually downloaded, patched, compiled, and installed a new bash, you should test it to make sure you’re no longer vulnerable. Make sure your current shell session is using your newly compiled bash by simply running the new location from the command line. In this example, that would be:

PowerShell

/bin/bash

1

/bin/bash

First, check to make sure you’re running the newly compiled version with:

PowerShell

bash --version

1	bash --version

The output should look like:

PowerShell

GNU bash, version 4.0.42(1)-release (i686-pc-linux-gnu)

1	GNU bash, version 4.0.42(1)-release (i686-pc-linux-gnu)

The 4.0.42 means you’re running Bash 4.0 at patch level 42. If that was the highest patch you applied to your source, then you are running the version you just built. Now run the vulnerability tests at the top of the article again. As I stated earlier, it’s possible that patches aren’t available to address all of them yet, but you should still patch to the highest level available, and then check back frequently to see if newer patches are available. Also, make sure you log out of any current shell sessions, and log in again using your new shell.