VMware Cloud Community
pmorrison
Enthusiast
Enthusiast

Installing ESX at a DoD facility

In order to have ESX connected to a DoD network you must pass the STIG requirements. When doing this you get several false findings like this:

PDI Number: IAVA0360

Finding Category: CAT I

Reference: IAVA 2003-A-0015

Description: There are multiple vulnerabilities in OpenSSL.

Status: Open

For example:

IAVA0360: IAVA 2003-A-0015

/usr/bin/openssl version 0.9.7a found on esx.fqdn.com 2.4.21-47.0.1.ELvmnix.

From conversations with others this is supposed to be a false finding and there are even kb articles that state such but they all refrence ESX 1.x and 2.x but nothing regarding 3.0.x or higher...

Does anyone have information that proves that this is a false finding?

0 Kudos
30 Replies
surfup
Enthusiast
Enthusiast

Thanks for the info.

As you mentioned PowerShell, is there a way to script and run these two commnands to shutdown web access? We have quite a few ESX 3.5 update 3hosts already out there and if we can automate the task the less prone the users will screw up. Thanks.

PS: I am more familiar with Windows scripting side.

Cheers,

0 Kudos
admin
Immortal
Immortal

See the following KB article (very recently released) that talks about the OpenSSL False Positives.

Note that from what we have seen Retina only looks for version numbers and doesn't actually look for the presence of the vulnerability or the individual implementation of the package.

On another note, SSLv2 is actually off by default in ESX3.5, so I am guessing what you are seeing is the issue about use of weak ciphers. This is currently being addressed and a patch will be available at some point in the future, but the risk of this issue is extremely low, unless you are using a very old browser that only uses weak encryption. So while the vulnerability is present, the risk of exploitation is extremely low.

0 Kudos
dmaahs
Contributor
Contributor

I am just learning Powershell now and have not used that function myself, but the set-vmhostservice command will do what you need. Here are some links that have examples.

rrandell, I agree that the openSSL issue is not CVE based, but the problem is it using v2. We frequently have to deal with Retina finding things running; http, ftp, samba, etc. All that is stated is X service is running. Our response is yes it is and is needed. Similar here. Since DoD is using Retina and the audits file is configured to scan for not only things from the STIGs but also standard stuff that Retina wants to include, we have to respond to any findings. Silly, False Positive or otherwise. In this case it does not look at the version of openSSL, the SRR scans take care of that. Retina just checks the encryption level used and says you need to be better than v2. So while the risk is low, just because Retina finds it, it still has to be addressed by a fix or some sort of mitigation paperwork.

0 Kudos
admin
Immortal
Immortal

Are you still on 3.0.2 or on 3.5? SSLv2 should be disabled by default on 3.5.

Rob Randell, CISSP | VMware | Senior Systems Engineer - Security | Office/Mobile: 303.324.2331 | email: rrandell@vmware.com

Sent from Blackberry. Please excuse typos or terse responses.

0 Kudos
dmaahs
Contributor
Contributor

Still on 3.0.2, reviewing if I should go to 3.5 or right to 4 since I need to be completed by 8/8.

0 Kudos
Texiwill
Leadership
Leadership

Hello,

THere are other tools available that will actually search for the vulnerability in SSL, one of them is Nessus. Tools like nessus actually LOOK for the vulnerability and do not just view version numbers as Nessus is an external tool.


Best regards, Edward L. Haletky VMware Communities User Moderator, VMware vExpert 2009, DABCC Analyst[/url]
Now Available on Rough-Cuts: 'VMware vSphere(TM) and Virtual Infrastructure Security: Securing ESX and the Virtual Environment'[/url]
Also available 'VMWare ESX Server in the Enterprise'[/url]
[url=http://www.astroarch.com/wiki/index.php/Blog_Roll]SearchVMware Pro[/url]|Blue Gears[/url]|Top Virtualization Security Links[/url]|Virtualization Security Round Table Podcast[/url]

--
Edward L. Haletky
vExpert XIV: 2009-2023,
VMTN Community Moderator
vSphere Upgrade Saga: https://www.astroarch.com/blogs
GitHub Repo: https://github.com/Texiwill
0 Kudos
dmaahs
Contributor
Contributor

We would prefer that over what Retina gives us, but unfortunately Retina is currently the DISA approved external scan tool. And anything it spits out as a finding has to be addressed. It would be nice if it could be replaced by a better tool like Nessus, but I won't hold my breath.

0 Kudos
surfup
Enthusiast
Enthusiast

Thanks RRandell and that KB help a lot.

Also, for ESX 3.5, do you know how to find out what version of OpenSSL is unning?

Cheers,

0 Kudos
admin
Immortal
Immortal

I believe this command will do it.

openssl version –v

0 Kudos
Texiwill
Leadership
Leadership

Hello,

I do know some companies that have replaced their version of openssl/openssh with newer or different tools. However if you do so you will need to test it extremely well to make sure nothing breaks your management and administration tools. It could also affect your warranty when reporting a problem to VMware.


Best regards, Edward L. Haletky VMware Communities User Moderator, VMware vExpert 2009
Now Available on Rough-Cuts: 'VMware vSphere(TM) and Virtual Infrastructure Security: Securing ESX and the Virtual Environment'[/url]
Also available 'VMWare ESX Server in the Enterprise'[/url]
[url=http://www.astroarch.com/wiki/index.php/Blog_Roll]SearchVMware Pro[/url]|Blue Gears[/url]|Top Virtualization Security Links[/url]|Virtualization Security Round Table Podcast[/url]

--
Edward L. Haletky
vExpert XIV: 2009-2023,
VMTN Community Moderator
vSphere Upgrade Saga: https://www.astroarch.com/blogs
GitHub Repo: https://github.com/Texiwill
0 Kudos
surfup
Enthusiast
Enthusiast

Thanks RRandell.

As a note, I ran the OpenSSL to check the version on my ESX 3.5 Update 3 hosts, and they both repored OpenSSL version 0.9.7a (Feb 03, 2003). This is the same OpenSSL version with vulnerrables reported in IAVA 203-A-0015 and IA VA 2008-A-0036 listed as CAT I.

The IAVA 20098A-0036 was superceded by A-2009-0001 and then again by 2009-A-0023. The 2009-A-0023 was address in VMSA-2009-0004.1. Have anyone apply the patches in VMSA-2009-0004.1 and validated that it indeed fix the CAT I isssue?

Cheers,

0 Kudos