PCI compliance - TLS protocol renegotiation vulnerability

ibm

Verified User
Joined
Jan 30, 2014
Messages
6
I am trying to get PCI compliance, I have everything sorted except for the following error on port 2222

Title: TLS Protocol Session Renegotiation Security Vulnerability
Impact: The vulnerability allows man-in-the-middle attack.
Resolution: For OpenSSL, [http://www.openssl.org/source/] upgrade to 0.9.8l or higher.
For Microsoft IIS web servers, install the appropriate patch available through [http://technet.microsoft.com/en- us/security/bulletin/MS10-049] Microsoft Security Bulletin 10-049.
For other types of products, consult the product documentation.
Risk Factor: Medium/ CVSS2 Base Score: 5.8
(AV:N/AC:M/Au:N/C:N/I:P/A:P) CVE: CVE-2009-3555 BID: 36935

The OpenSSL version on the server is 1.0.1, I assume this is something that needs to be configured in directadmin.conf but I am not sure what it needs to be.

Any help would be greatly appreciated.
 
Hello,

Which OS are you running?
The DirectAdmin binaries are compiled on the stock openssl that comes with the OS on our build systems.
If the newer version is not available for that OS, we don't manually add or compile openssl, else when DA is installed, it wouldn't be linked against the correct files.

Short answer, if you're using an OS that comes with an older version of openssl, you'd need to install to a newer OS such that our DA binaries are linked against the required openssl version (eg: our build box needs to have that openssl version, or higher).

John
 
Hello,

Which OS are you running?
The DirectAdmin binaries are compiled on the stock openssl that comes with the OS on our build systems.
If the newer version is not available for that OS, we don't manually add or compile openssl, else when DA is installed, it wouldn't be linked against the correct files.

Short answer, if you're using an OS that comes with an older version of openssl, you'd need to install to a newer OS such that our DA binaries are linked against the required openssl version (eg: our build box needs to have that openssl version, or higher).

John

Hi John,
It is running on CentOS 6.5 (CentOS 6.4 at the time of installation). Is there no way to update the binaries to support this? Does that mean the only way to get over this problem is to completely reinstall the server?
Cheers.
 
If that's the latest version of CentOS 6, then it's likely the fixes to OpenSSL to make it compliant are likely already backported into the version included in the base OS. Red Hat (and therefore CentOS) do not increase version, but backport against all vulnerabilities.

It's likely that whomever is testing your server isn't testing, but just checking version numbers.

What company are you using for PCI compliance? Have you asked them if they actually test, or if they just check version numbers? What was their reply?

And of course have you updated DirectAdmin to the latest version?

If you're running compliant oftware (you can test it yurself, but don't ask me how; I don't know), and your PCI compliance checking organization won't test it and pass it, then you still have a problem, but perhaps it can be rectified by discussions with them.

Note that all PCI compliance is most certainly not equal.

Jeff
 
The server already has the patched versions of openssl (it is running 1.0.1) and tests are fine on port 443. It is only the directadmin webserver on 2222 that has this issue. Directadmin version is 1.44.3 which appears to be the up to date version. We are using SecurityMetrics, have contacted them and they did a manual test. I also tested it myself and it does allow renegotiation on port 2222.

Thanks.
 
Hello,

Again, directadmin is a pre-compiled binary.
The only way to have your version of openssl compiled into DA is to give you the source code, and unfortunately, that's not going to happen.

The DA binaries are compiled with the openssl version for the given OS.. so the only way to get the newer version of openssl is to use the DA binaries that are compiled against the newer openssl, which typically requires a newer OS (this can be changed in your license to get different DA binaries).. but of course, if the new OS binaries are on an old OS, then they probably won't run at all.

John
 
What I've just done is updated all libraries on our CentOS 6 64-bit box, and recompiled DirectAdmin.
This included the OpenSSL package 1.0.1, as mentioned.

The updated binaries for CentOS 6 64-bit can be downloaded from the pre-release section:
http://help.directadmin.com/item.php?id=408

Let me know us know the result, either way.

John
 
What I've just done is updated all libraries on our CentOS 6 64-bit box, and recompiled DirectAdmin.
This included the OpenSSL package 1.0.1, as mentioned.

The updated binaries for CentOS 6 64-bit can be downloaded from the pre-release section:
http://help.directadmin.com/item.php?id=408

Let me know us know the result, either way.

John

Thanks for this, unfortunately it doesn't seem to have worked. It is still allowing renegotiation.

Cheers.
 
Hello,

1) You're using a 64-bit box? "uname -m". Also confirm you've got the latest binaries (compile date should be yesterday):
Code:
./directadmin o
2) What ciphers are being used?
Code:
./directadmin c | grep ssl_cipher
3) Confirm which libssl.so.X files DA is linked to, eg:
Code:
ldd directadmin | grep libssl.so
Then run that library through "rpm" to see which package it belongs to, eg:
Code:
rpm -qf /usr/lib64/libssl.so.10
Not sure what else there is to check if all of the above is set correctly.

If the issue is directly in the openssl libraries themselves, and anything later than 0.9.8l is resolved..and we're using 1.0.1, then the other possibility is that you're not actually affected and their test isn't checking the issue correctly. DA isn't exactly up to the same level as apache, when it comes to SSL handling, so perhaps a check isn't looked at correct for DA's case. Eg: possible false positive.

If you are in contact with the PCI Compliance team who are doing the test, ask them exactly what test they're conducting to conclude that you're affected by this issue.
If they're finding openssl 0.9.8l in the SSL handshake, then something isn't right.. as that version doesn't exist on the box it was compiled on. (Not sure it actually ever did.. I believe it was 1.0.0 before updating to 1.0.1)

John
 
I've done more digging, reading, scouring, followed by some re-coding of DA itself.
I've uploaded a new set of binaries, give it another try now.

The change will do an active disconnect on SSL renegotiation if the first handshake has already happened.
It uses an SSL callback function for ssl triggers to figure that out.
You'll see this error in the error.log
Code:
SSL Renegotiation disabled.
Versions entry:
http://www.directadmin.com/features.php?id=1555

John
 
I've done more digging, reading, scouring, followed by some re-coding of DA itself.
I've uploaded a new set of binaries, give it another try now.

The change will do an active disconnect on SSL renegotiation if the first handshake has already happened.
It uses an SSL callback function for ssl triggers to figure that out.
You'll see this error in the error.log
Code:
SSL Renegotiation disabled.
Versions entry:
http://www.directadmin.com/features.php?id=1555

John

The new binaries worked a treat and the server is now showing as PCI compliant. Thanks for all your help.
 
Back
Top