[Year 12 SofDev] Hardened PHP Project

[stephen at melbpc.org.au]

Hardened PHP Project, 2007

<http://www.php-security.org/>

This initiative is an effort to improve the security of PHP. We will 
concentrate on security vulnerabilities in the PHP core. 

During March 2007 old and new security vulnerabilities in the Zend 
Engine, the PHP core and the PHP extensions will be disclosed on a day by 
day basis. 

We will also point out necessary changes in the current vulnerability 
management process used by the PHP Security Response Team. 

Esser, widely regarded as an authority on PHP security issues, plans to 
make daily disclosures on buffer overflows, double free vulnerabilities 
and trivial bypass bugs in PHP’s protection features as part of a wider 
goal “to make people and especially the PHP developers aware that bugs in 
PHP exist.”

In an interview with SecurityFocus, the German researcher did not hide 
his disdain for the way PHP security issues are handled by the open-
source group that maintains the Apache-backed project. “PHP has a very 
bad reputation when it comes to security, which is mostly caused by all 
the advisories about security holes in PHP applications,” he declared, 
arguing that the situation is inflamed by the PHP Group’s insistence on 
blaming programmers for insecure coding practices.

“Remote File Inclusions, vulnerabilities due to register_globals or other 
problems within the PHP engine (e.g. zend_hash_del_key_or_index bug) are 
fully to blame on the PHP language. Unfortunately this kind of thinking 
is not appreciated by the PHP developers and they continue to claim that 
PHP is not worse than other languages, and that only badly written PHP 
applications are the problem. The Month of PHP bugs will show however 
that a lot of bugs in PHP’s own source code exist,” Esser added.

Esser’s flaw disclosure project will only release information on holes 
within the code shipped with the default distribution of PHP. “That means 
we will not disclose holes in extensions that only exist in PECL, while 
we are sure that those contain vulnerabilities, too. Most of the holes 
were previously disclosed to the vendor, but not all,” he explained.

On some days in March, because of the volume of PHP bugs stockpiled, he 
said there will be more than one vulnerability disclosed.

“As a vulnerability reporter you feel kinda puzzled how people among the 
PHP Security Response Team can claim in public that they do not know 
about any security vulnerability in PHP, when you disclosed about 20 
holes to them in the two weeks before. At this point you stop bothering 
whether anyone considers the disclosure of unreported vulnerabilities 
unethical. Additionally a few of the reported bugs have been known for 
years among the PHP developers and will most probably never be fixed,” he 
argued.

The issue of PHP security has been on the front burner lately, driven 
mostly by a dramatic rise in exploitable flaws in PHP-based Web 
applications.
--

Cheers, people
Stephen Loosley
Victoria, Australia