I decided to test them. At first I was baffled--what reason does VMware itself have to use openssl? I thought the Mac OS X underneath it would do that. But I realized that the update process probably used an HTTPS connection, and I guess it's possible that VMware uses its own openssl to do that, for some reason.
All tests are on a MacBook Air, running Mavericks OS X 10.9.2.
I started Wireshark sniffing, and then started VMware Fusion.
It checks for updates.
Referring to the image below, I found these interesting facts:
sudo nano /etc/hosts
At the end of the file, I added these lines:
199.188.72.153 ueip.vmware.com
199.188.72.153 softwareupdate.vmware.com
I saved the file.
Then I used this command to clear the DNS cache.
sudo killall -HUP mDNSResponder
I restarted Wireshark sniffing, and then
restarted VMware Fusion.
As shown below, VMware now connects to my malicious server, and the server sends a heartbeat request in packet 171, but VMware never responds with a heartbeat.
I also tried redirecting "softwareupdate.vmware.com" with the same result: it now connects to my server, gets a malicious heartbeat request, but does not respond.
I tried it a few times, checking both connections, and it never responds to the heartbeat.
But the same thing happens: heartbeat requests remain unanswered:
I must be missing some other way to attack it, because VMware says it's vulnerable.