2

We are currently trying to achieve PCI compliance using Trustwave's vulnerability scanner.

The Magento version is 1.5.1.0, 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:

Issue:

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.

My Dispute

(As with all other issues I submitted a list of exact versions that we are using).

Apache: httpd-2.2.3-45.el5.centos.1

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

SSL: mod_ssl-2.2.3-45.el5.centos.1

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).

CVE Link http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-1938

We were wondering if anyone had managed to get around this issue with Magneto 1.5.1.0 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.

https://www.redhat.com/security/data/cve/CVE-2011-1938.html

"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.

dannymcc
  • 2,717
  • 10
  • 48
  • 72
  • I was kinda shocked to see this fix was applied back in May, but not picked up by all vendors. – Ryan Gibbons Aug 13 '11 at 15:06
  • I think their logic is something along the lines of "most people don't use that function." It's a very unfortunate reaction. – Jeff Ferland Aug 13 '11 at 17:58
  • I would dispute their declination based on the fact that the fix is not available to your system but will be applied as soon as it becomes available. – daemonofchaos Nov 06 '12 at 19:46

3 Answers3

3

That sucks. It really sucks because PHP's current stable revision is still the vulnerable one. Here's what you do (yay open source!):

Alternately, you can use one of the upcoming release candidate version. I'd personally prefer patching the stable one, though.

Your auditor did the right thing, though. RedHat really should as well... that's an easy package fix... http://www.securityfocus.com/bid/47950/exploit

Jeff Ferland
  • 20,547
  • 2
  • 62
  • 85
3

It looks like 5.3.7 will contain the fix. If you can, I say hang in there and wait for the release. According to the mailing list, 5.3.7 RC5 was Aug 11 to fix a couple of regressions in RC4 and are hoping to have the final release happen this coming week.

I'm not sure the time frame, so I don't know how likely this will help you.

BTW, Line 286 on the NEWS shows the fix

Ryan Gibbons
  • 998
  • 9
  • 20
0

Also consider turning off expose_php which is a best practice.

I have seen turning that off doesn't give similar scanners the information they need to determine if you are vulnerable. Plus it doesn't give attackers the same information.

http://www.php.net/manual/en/ini.core.php#ini.expose-php

runamok
  • 163
  • 10