Most PCI compliance scanning systems are based on a specific version number of a software package that has a reported vulnerability. However, many operating systems use backporting to update the software packages they distribute rather than distributing a whole new version of the software package. Backporting allows the operating system vendor to change only the parts of the software affected by the security vulnerability without introducing new features that have not yet been tested. In backporting, the software version number is not incremented but instead a flag is attached.
For example: OpenSSL 0.9.7c may be updated with a backport to OpenSSL 0.9.7c-2 rather than fully updating to OpenSSL 0.9.7d. Most PCI scanning systems look only for 0.9.7d or higher and therefore, incorrectly show 0.9.7c-2 as vulnerable. In this case, the PCI compliance company should be informed that you are using a backported version of the software package which has been patched for the vulnerability. Once properly informed, they can record your software version and mark a false positive in the scan results. Below, we will discuss some specific software packages and how to determine if vulnerabilities have been patched by backporting.
OpenSSL
Primarily, it is important to note that OpenSSL is used by a number of different system services and packages. You should only replace your OpenSSL installation as a last resort.
In order to determine which OpenSSL package is installed on your system, run the following command:
rpm -qa | grep openssl
The output should resemble the following:
root@myserver:/# rpm -qa | grep openssl
openssl-devel-0.9.8b-10.el5
openssl-0.9.8b-10.el5
This means that your currently installed OpenSSL package is
openssl-0.9.8b-10
Now, you can check the RPM change log to see if the vulnerability fix was included in that version:
root@myserver:/# rpm --changelog -q openssl-0.9.8b-10.el5 | less
In this case, we see that in 0.9.8b-9, three CVE reports were fixed. This should match any CVEs that your PCI compliance scanning company would want to have fixed.
You can now inform the PCI compliance scanning company of the patched version and which CVEs it reflects so they can mark this as a false positive.
mod_frontpage
Many PCI scans will note the Apache mod_frontpage module as vulnerable to a buffer overflow error which may cause privilege escalation, including root access. This is based on the default Apache installation and not valid in cPanel's environment. A typical scan may provide these results:
TCP 443 https 7
The remote host is using the Apache mod_frontpage module. mod_frontpage older than 1.6.1 is vulnerable to a buffer overflow which may allow an attacker to gain root access. Since we are not able to remotely determine the version of mod_frontpage you are running, you are advised to manually check which version you are running as this may be a false positive. If you want the remote server to be remotely secure, we advise you do not use this module at all.
Solution: Disable this module
Risk Factor: High
CVE : CVE-2002-0427
When using a cPanel configured Apache, the
fpexe FrontPage binary is configured differently than on a default installation
Apache 2
With Apache 2.x, 2.2.x, 2.4.x compiled through EasyApache,
fpexe is replaced by
/scripts/fp-auth which is never setuid root.
Apache 1
With Apache 1.3.x compiled through EasyApache,
fpexe is custom built from the shared files in
/scripts/fetchfpexec,
/scripts/fpexec3 and
/scripts/fp3.
fpexec will only be setuid if Apache's suexec functionality is disabled. Even with
suexec disabled,
fpexec is not directly executing the Frontpage binaries.
fpexe hands the work off to
/scripts/fp-auth which does additional access checks.
Apache 1 or 2 compiled through cPanel's EasyApache system does not leave a system vulnerable to the exploit noted in the CVE report.
/scripts/fp-auth prevents the privilege escalation scenario from occurring.
Note: We do not recommend the use of
mod_frontpage based on compatibility and support. The module is no longer supported by any upstream development team and has reached End-Of-Life. While we will continue to support
mod_frontpage as long as it is practical to do so, there are better publishing methods available. We recommend you enable WebDAV (cpdavd) to publish files, as it provides enhanced security and stability and is an actively supported protocol.
cPanel & WHM creates patches for Exim to help make Exim PCI compliant. Change Log patches should always be included in the RPM.
You can use the PCI scanning software to determine which ciphers are allowed to be used during an encrypted communication. To adjust your Cipher Keys for PCI Compliance, follow these steps:
PCI Compliance requires email client encryption. Encryption is provided in your email client as SSL and TLS. To enable encryption of your SMTP transactions, follow these steps:
The output will display the CVE number you must fix. You should send the output that reflects the patched software to the PCI scanning company.
Although cPanel & WHM does not create BIND, BIND is installed on all cPanel servers by default.. Vendor updates will typically resolve PCI compliance issues.
The BIND change log does not show CVE-2011-4313 directly. Instead, the change log shows under RHEL #754398.
You should send the output which reflects the patched software to the PCI scanning company.
You should rescan your server with your account on the PCI company's website.
To become PCI compliant, your DNS server’s hostname must be hidden.
You should rescan your server with your account on the PCI company's website.
Mailman can be completely disabled when you scan for PCI Compliance.
This will deny web requests for Mailman. After you finish these steps, rescan your server with your account on the PCI company's website.