We are currently trying to achieve PCI compliance using Trustwave's vulnerability scanner.
The Magento version is 188.8.131.52, running on CentOS 5.
We am down to the last issue according to the PCI Compliance report. We have disputed the issue but they have declined. Here are the details:
The version of PHP running on this host is prone to a stack-based buffer overflow in the socket_connect function in ext/sockets/sockets.c which could allow context-dependent attackers to execute arbitrary code via a long pathname for a UNIX socket.
This vulnerability has been addressed in a soon to be released version of PHP, however, backported fixes to this issue may exist. Your vendor should be contacted to determine if a solution is currently present.
Alternatively, removing the use of the socket_connect function from all PHP applications will also mitigate this issue.
(As with all other issues I submitted a list of exact versions that we are using).
PHP: php-common-5.3.6-3.el5.art php-5.3.6-3.el5.art php-mbstring-5.3.6-3.el5.art php-pear-1.7.2-2.el5.art
SSH: openssh-4.3p2-72.el5_6.3 openssh-server-4.3p2-72.el5_6.3
Reason for declinature
We have denied this dispute based on the information provided indicating that php-5.3.6-3.el5.art is running on this system.
Documentation showing that this version addresses php-5.3.6-3.el5.art could not be found.
Please re-dispute this vulnerability and provide more detail or evidence that this version has successfully addressed this finding (such as by providing a vendor supplied link along with an explanation/statement showing that this version addresses CVE-2011-1938).
We were wondering if anyone had managed to get around this issue with Magneto 184.108.40.206 and PCI vulnerability testers?
Our service provider (web host) kindly gave us this response:
Magento uses socket_connect quite extensively I believe. As I said in a previous mail, I believe that Red Hat have de-prioritised the urgency of patching this particular bug and as of yet, have not fixed it.
"The Red Hat Security Response Team has rated this issue as having low security impact, a future update may address this flaw."
The fix has not been implemented in the Atomic Corp versions of the packages either. I guess the next step may be to consider compiling PHP from the Atomic source packages and manually fixing the bug, but it may not be enough to satisfy the auditors without supporting documentation from a recognised security body.
We we're hoping someone has come across this issue before and knows a workaround.