Is Zend Server really secure?

[smoorsn0ek]

Hi,

Zend Server 5.6.0 uses PHP 5.3.14 - which has a number of known vulnerabilities. eg:

PHP 'phar_parse_tarfile' Integer Overflow Vulnerability - http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-2386
PHP '_php_stream_scandir' Overflow Vulnerability - http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-2688
PHP 'com_print_typeinfo' Buffer Overflow Vulnerability - http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-2376
PHP 'php-cgi' Information Disclosure Vulnerability - http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-2336
PHP 'php-wrapper.fcgi' Information Disclosure Vulnerability - http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-2335
PHP 'php-cgi' Command Line Argument Injection Vulnerability - http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-2311

I cannot find anywhere identifying whether or not these vulnerabilities have been addressed in Zend Server.

Can anyone explain how Zend makes Zend Server customers aware of which security issues have been addressed?

thanks

[smoorsn0ek]

As a commercial PHP stack provider I would expect security to be both taken extremely seriously and well documented.

Is there seriously no one at Zend who can answer this question in like 3 seconds?

[smoorsn0ek]

Well - I'm blown away by the lack of response.

As I know that Zend staff look at these bulletin boards, I can only conclude that Zend has no answer they are comfortable to provide and thus that Zend Server is not protected from the listed vulnerabilities. ie. is insecure.

[idobms]

Zend constantly monitors security and vulnerability reports in PHP and other elements of the application stack delivered by Zend Server. High severity security issues are in general identified as remotely exploitable security vulnerabilities that pose a threat to the application execution or compromise its data. Local exploits are typically not considered severe threats. Not all CVE’s that are picked by PCI scanners and such automated tools are relevant to Zend Server and some of these apply to configurations that are not supported or sometimes issues already addressed by Zend in a prior PHP version. You can find some initial assessments regarding your list below. If you have specific questions regarding one of the CVE’s or concerns regarding an unhandled severe remote exploit we can forward to the developers to get more insight.

CVE-2012-2311: PHP 5.3.13/5.4.3 changelog - [bug #61910 Improve fix for PHP-CGI query string parameter vulnerability]- Not relevant for FastCGI.
CVE-2012-2335: no PHP bugs found - Not relevant for FastCGI.
CVE-2012-2688 related to _php_stream_scandir function - It has no remote exploit implications.
CVE-2012-2386 - Addressed in PHP 5.3.14
CVE-2012-2376 – seems to be a PHP 5.4.3 issue only on Windows in the COM extension. Not addressed yet and I believe it has no remote exploit implications.
CVE-2012-2336: no PHP bugs found - Not relevant for FastCGI.

[smoorsn0ek]

Thank you for your reply and for your comments.

While the observations are useful, what I would like to see from Zend is a published CVE list showing all PHP threats affecting the versions of PHP run by Zend Server and the current status/impact of those threats.

Generally I believe this is important for the Zend server's security credibility, and specifically it is important to us as a business for 2 reasons:

1. It provides our developers the ability to understand and potentially code for threats that exist where necessary.

2. it provides our sales team with the ability to answer our customers when their security experts ask "what version of php are you running?" and then follow the question up with a list of known CVEs for that version asking "are these known CVEs handled?"

Thanks again

[osuresearch]

I'm glad it's not just me. Here's an ongoing support ticket re: vulnerabilities corrected in PHP 5.3.15 (Zend server is 5.3.14, I believe):

---- Zend response when I pointed out vulnerabilities that I am REQUIRED to address by my institution ---

Since PHP is open source we build our own build of it for Zend Server. We usually backport patches that are resolving the vulnerabilities in specific PHP versions.

My guess if your security audit is only checking the PHP version and not actually exploiting the system.

We are aware of the two reports you have listed.
CVE-2012-3365
CVE-2012-2688

Both are not remotely exploitable and considered to be low priority issues.

I'm checking the status of SP5 update of Zend Server , which should have the PHP version number change. As far as I understand once your have the newer PHP version listed in phpinfo your audit system will stop generating alerts.

Regards,
Nick
Zend Global Support

--------------- Original Message ---------------
This still doesn't address the overall concerns of the organization. Essentially it boils down to this:

We need to patch critical vulnerabilities as quickly as possible. The fix for these has been available in the general PHP release for months. The Zend server release hasn't been updated since BEFORE these vulnerabilities were even discovered.

Arguing that they aren't subject to remote exploitation isn't really an answer. So, I'm left with either having to migrate to a non-Zend PHP distribution or shutting down my production web servers.

Please advise.

Thanks,
John
---

[zeev]

John, all,

While I agree we should have a clear web page explaining the different CVEs and their applicability to Zend Server, Zend only produces updates for remotely exploitable issues. In fact, we don't consider non-remotely-exploitable issues as security issues at all.

FYI, there are discussions on php.net happening regarding whether or not issues that require developer access should even be reported as CVEs at all, as protecting PHP against a malicious developer is a hopeless endeavor to begin with.

We'll look into providing this information in a better way, so that you can know whether a particular CVE is something to worry about or not. The VAST MAJORITY of PHP CVEs are actually completely meaningless from a security perspective. In fact, the last real security issue in PHP was exactly one year ago, and was released by Zend at the same time as it became available as a part of a new PHP release.