This initiative is an effort to improve the security of PHP. However we will not
concentrate on problems in the PHP language that might result in insecure PHP
applications, but 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.
(Hardened-PHP Project, 2007).
(B) Bonus Vulnerability not in PHP
|46||PHP ext/session Session Cookie Parameter Injection Vulnerability (U)||The session id does not get urlencoded before it is sent within the cookie. Therefore it is possible to inject arbitrary cookie parameters like a very long lifetime depending on PHP version and selected session module.||Not needed||HPHP-01-2006|
|45||PHP ext/filter Email Validation Vulnerability||A wrong regular expression in the email validation filter allows injection of a single newline at the end.||Not needed||CVE-NO-NAME|
|44||PHP 5.2.0 Memory Manager Signed Comparision Vulnerability||Due to a signed integer comparison the request for more than 2 GB of memory will be answered with a minimum size memory block. This results in a myriad of (sometimes remotely) exploitable buffer overflows.||Soon||CVE-2007-1889|
|43||PHP msg_receive() Memory Allocation Integer Overflow Vulnerabilty||An unchecked maxsize parameter to the msg_receive() function can result in an integer overflow during memory allocation that results in an exploitable buffer overflow.||Soon||CVE-2007-1890|
|42||PHP 5 php_stream_filter_create() Off By One Vulnerablity||The internal wildcard handling for stream filters contains an exploitable off by one overflow vulnerability that can be triggered by accessing a php://filter URL.||Soon||CVE-NO-NAME|
|41||PHP 5 sqlite_udf_decode_binary() Buffer Overflow Vulnerability||Calling sqlite_udf_decode_binary() with a malformed input string can lead to an exploitable buffer overflow.||Soon||CVE-2007-1887|
|40||PHP imap_mail_compose() Boundary Stack Buffer Overflow Vulnerability||An overlong boundary string passed to imap_mail_compose() will overflow a stack buffer and lead to arbitrary code execution.||Soon||CVE-NO-NAME|
|39||PHP str_replace() Memory Allocation Integer Overflow Vulnerability||When a single char is replaced by a long string many times in str_replace() this can result in an integer overflow in memory allocation that leads to a buffer overflow vulnerability.||Soon||CVE-2007-1885|
|38||PHP printf() Family 64 Bit Casting Vulnerabilities||A 64 bit long to int cast results in multiple flaws in PHP's printf() function family that lead to a new class of exploitable vulnerabilities. PHP Application Format String Vulnerabilites.||Soon||CVE-2007-1884|
|37||PHP iptcembed() Interruption Information Leak Vulnerability (U)||A malicious user space error handler that interrupts iptcembed() can manipulate its parameters which leads to disclosure of arbitrary heap memory.||MOPB-37-2007.php||CVE-2007-1883|
|36||PHP session.save_path open_basedir Bypass Vulnerability||Due to some magic directory guessing a script can bypass the open_basedir restriction on the session save path.||Not needed||CVE-NO-NAME|
|35||PHP 4 zip_entry_read() Integer Overflow Vulnerability||The zip_entry_read() function of PHP 4 is vulnerable to an integer overflow in memory allocation that leads to an exploitable bufferoverflow.||MOPB-35-2007.php
|34||PHP mail() Header Injection Through Subject and To Parameters||A flaw in handling folded Subject and To headers allows mail header injection through both fields.||Not needed||CVE-NO-NAME|
|33||PHP mail() Message ASCIIZ Byte Truncation||ASCIIZ character injection into an email message will truncate it.||Not needed||CVE-NO-NAME|
|32||PHP 4.4.5/4.4.6 session_decode() Double Free Vulnerability||The security fix for MOPB-31-2007 introduced a double free vulnerability into PHP 4 that can lead to the execution of arbitrary code.||MOPB-32-2007.php||CVE-NO-NAME
|31||PHP _SESSION Deserialization Overwrite Vulnerability||Deserialization of session data can overwrite _SESSION which can be exploited to execute arbitrary code.||MOPB-31-2007.php||CVE-NO-NAME|
|30||PHP _SESSION unset() Vulnerability||Unsetting HTTP_SESSION_VARS and _SESSION can lead to arbitrary code execution.||MOPB-30-2007.php||CVE-NO-NAME|
|29||PHP 5.2.1 unserialize() Information Leak Vulnerability||The new S: datatype in unserialize() does not work at all which leads to disclosure of heap memory content.||MOPB-29-2007.php||CVE-NO-NAME|
|28||PHP hash_update_file() Already Freed Resource Access Vulnerability (U)||A malicious user stream can trick the hash_update_file() function into accessing an already freed hash resource. This can lead to arbitrary code execution.||MOPB-28-2007.php||CVE-NO-NAME|
|27||PHP ext/gd Already Freed Resource Access Vulnerability (U)||A malicious error handler can trick the GD extension into accessing an already freed image resource which allows read and write access to arbitrary memory addresses from PHP code. This can lead to arbitrary code execution.||MOPB-27-2007.php||CVE-NO-NAME|
|26||PHP mb_parse_str() register_globals Activation Vulnerability (U)||When the mb_parse_str() function is interrupted by for example a memory_limit violation this can result in register_globals being (and staying) activated for the Apache child.||MOPB-26-2007.php||CVE-NO-NAME
|25||PHP header() Space Trimming Buffer Underflow Vulnerability||When the header() function is called with an all whitespace string a buffer underflow can be triggered that allows code execution on big endian systems (e.g. MacOS X on PPC, Solaris on SPARC)||MOPB-25-2007.php||CVE-NO-NAME
|24||PHP array_user_key_compare() Double DTOR Vulnerability||When the userspace key comparison function returns its parameters are destructed even if there are references left. Therefore an exploitable double DTOR can be triggered.||MOPB-24-2007.php||CVE-NO-NAME|
|23||PHP 5 Rejected Session Identifier Double Free Vulnerability||When a session storage module rejects a session id the session code fails to clear an already freed pointer before calling an interruptible function. This can lead to an exploitable double free.||MOPB-23-2007.php||CVE-NO-NAME
|22||PHP session_regenerate_id() Double Free Vulnerability||session_regenerate_id() fails to clear an already freed pointer before calling an interruptible function. This can lead to an exploitable double free.||MOPB-22-2007.php||CVE-NO-NAME|
|21||PHP compress.bzip2:// URL Wrapper safemode and open_basedir Bypass Vulnerability||The compress.bzip2:// URL Wrapper does not perform safemode or open_basedir checks and therefore allows access to archives outside the allowed area||Not needed||CVE-NO-NAME|
|20||PHP zip:// URL Wrapper safemode and open_basedir Bypass Vulnerability||The zip:// URL Wrapper does not perform safemode or open_basedir checks and therefore allows access to archives outside the allowed area||Not needed||CVE-NO-NAME|
|19||PHP ext/filter Space Trimming Buffer Underflow Vulnerability||When ext/filter is used in an application to filter user input a buffer underflow can be triggered that allows remote code execution on big endian systems (e.g. MacOS X on PPC, Solaris on SPARC)||MOPB-19-2007.php||CVE-NO-NAME|
|18||PHP ext/filter HTML Tag Stripping Bypass Vulnerability||When ext/filter is configured to strip characters with low ASCII values it is possible to bypass the HTML tag filter in an easy way.||Not needed||CVE-NO-NAME|
|17||PHP ext/filter FDF Post Bypass Vulnerability||POST data in the FDF format is not processed at all by ext/filter. When PHP is compiled with FDF support, sitewide enforced filtering will not be performed on it.||MOPB-17-2007.php||CVE-NO-NAME|
|16||PHP zip:// URL Wrapper Buffer Overflow Vulnerability||The zip:// URL wrapper suffers from a standard stack based buffer overflow that occurs when an overlong URL is parsed and can therefore lead to arbitrary code execution.||MOPB-16-2007.php||CVE-NO-NAME|
|15||PHP shmop Functions Resource Verification Vulnerability||The shmop functions do not verify that the supplied resource is of the correct type. This allows read and write access to arbitrary memory addresses and allows the execution of arbitrary code.||MOPB-15-2007.php
|14||PHP substr_compare() Information Leak Vulnerability||An integer overflow in the substr_compare() function allows reading arbitrary heap memory.||MOPB-14-2007.php||CVE-NO-NAME|
|13||PHP 4 Ovrimos Extension Multiple Vulnerabilities||The Ovrimos extension shipped with PHP 4 considers arguments as direct memory pointers. This allows direct memory access which leads to arbitrary code execution.||Not needed||CVE-NO-NAME|
|12||mod_security POST Rules Bypass Vulnerability (B)||An ASCIIZ character embedded in application/x-www-form-urlencoded POST data terminates the data in the eyes of mod_security, which results in a trivial way to bypass its rules.||Not needed||CVE-NO-NAME|
|11||PHP WDDX Session Deserialization Information Leak Vulnerability||Numerical keys in session data in WDDX format might leak an arbitrary portion of stack data into PHP variables.||MOPB-11-2007.php||CVE-2007-0908|
|10||PHP php_binary Session Deserialization Information Leak Vulnerability||Malformed session data in php_binary format might leak a portion of heap data into PHP variables.||MOPB-10-2007.php||CVE-NO-NAME|
|9||PHP wddx_deserialize() String Append Buffer Overflow Vulnerability||Malformed WDDX data might trigger an exploitable buffer overflow that was introduced by a pseudo security fix.||MOPB-09-2007.php||CVE-NO-NAME|
|8||PHP 4 phpinfo() XSS Vulnerability (Deja-vu)||phpinfo() does not escape the content of user supplied arrays in GET, POST or COOKIE variables when it displays them which leads to an XSS vulnerability.||MOPB-08-2007.phpt||HPHP-18-2005
|7||Zend Platform ini_modifier Local Root Vulnerability (B)||The ini_modifier of the Zend Platform can be tricked by a local user to edit the system php.ini file, which can be used to obtain root privileges.||Not needed||CVE-NO-NAME|
|6||Zend Platform Insecure File Permission Local Root Vulnerability (B)||Several binaries and shellscripts installed by the Zend Platform are installed with unsafe permissions that might allow an attacker to gain root privileges.||Not needed||CVE-NO-NAME|
|5||PHP unserialize() 64 bit Array Creation Denial of Service Vulnerability||Deserialisation of malformed PHP arrays from within unserialize() might result in a tight endless loop exhausting CPU ressources on 64bit systems.||Not needed||CVE-2007-0988|
|4||PHP 4 unserialize() ZVAL Reference Counter Overflow||During unserialisation of user supplied data that contains a lot of references to a variable the internal 16bit zval reference counter can overflow. This leads to an exploitable double dtor condition.||MOPB-04-2007.php||CVE-NO-NAME
|3||PHP Variable Destructor Deep Recursion Stack Overflow (U)||The destruction of deeply nested PHP arrays will exhaust all available stack which leads to remotely triggerable crashes.||Not needed||CVE-NO-NAME|
|2||PHP Executor Deep Recursion Stack Overflow (U)||A deep recursion of PHP userland code will exhaust all available stack which leads to a sometimes remotely triggerable crash.||Not needed||CVE-2006-1549|
|1||PHP 4 Userland ZVAL Reference Counter Overflow Vulnerability (U)||In PHP 4 userland code is able to overflow the internal 16bit zval reference counter by creating many references to a variable. This leads to an exploitable double dtor condition.||MOPB-01-2007.php||CVE-NO-NAME|
Frequently Asked Questions(FAQ)
The following list of questions and answers provides some information regarding the motives and related facts about the MOPB, such as involved products and disclosure terms. Please check that your question isn't already answered here before attempting to contact us. Any unsolicited e-mail, offensive or non-sense will be ignored.
- Is this an attack, revenge, conspiracy or some kind of evil plot against PHP, the PHP Group, the PHP Developers or the users of PHP?
- What kind of security bugs will be covered?
- Are PHP applications also a target of this initiative?
- Does the PHP Security Response Team know about these issues?
- Does "someone" pay, sponsor or support this? Is this initiative influenced in order to spread FUD over competitor's products?
- Why do you provide exploit code, isn't that irresponsible?
- Why do you report information leak vulnerabilities? They are not dangerous at all.
- Is this initiative affiliated with MOAB, MOKB, MOBB?
Not at all. The Hardened-PHP Project has improved the security of PHP for years by reporting serious
and sometimes not so serious security holes to the developers and the public. We also killed some
vulnerabilities in the PHP CVS snapshot versions before they ever made it into PHP releases. You should
consider the Month of PHP Bugs a result report for just another audit we did on PHP. Unfortunately when
you disclose security problems in someone else's code or in their bug handling process the developers
often feel hurt or attacked.
When people are interested we would like to host a PHP Audit Project where the PHP source code is checked by many eyes and not only by ours.
We will report different classes of security bugs. From simple denial of service bugs to potential remote code execution vulnerabilities.
No they are not. If you want a month of PHP application bugs you can subscribe to the bugtraq or full-disclosure mailinglists. Our initiative concentrates on bugs in the PHP standard distribution. However we might add some bonus bugs in software related to PHP but not PHP applications.
They got prior notification for many but not all of the bugs. Therefore some of the bugs are already fixed in the latest PHP releases and some not. Even when PHP developers get prior notice they usually endanger their users by commiting fixes to the PHP CVS tree and then they do not release new security fixed versions for several months.
This initiative is paid by the Hardened-PHP Project. With a little help from a hosting company that provided a mirror server. If you want you can support us by donating. However our goal is not to stop people from using PHP and therefore you waste your money if you want us to deliver FUD.
Exploit code is provided because on the one hand some people do not believe that a vulnerability is exploitable (maybe because their attempts failed) and on the other hand the lack of exploit code that tests for a certain vulnerability is the major reason why PHP vulnerabilities are sometimes not correctly fixed or why the same bugs are later reintroduced.
You are wrong. First of all some information leak vulnerabilities allow access to e.g. the Apache memory which might contain the private RSA key for the SSL cert. If an attacker is able to read it he can perform real man in the middle attacks on all SSL connections. Aside from this in the days of ASLR, NX and canary protections it is often vital for the success of the exploit to know exact memory addresses.
No it is not. Actually the MOPB differs from these initiative in several
points. First we disclose vulnerabilities in only one product and second
we do not enforce a one vulnerability per day limit upon ourself.
However you might have realised that the design for the MOPB looks partly like the MOAB site. We did this because it is clean and simple and because they gave their permission.
Press and pressure
What the media and press say about the MOPB:
- The year 2007: A review through the crystal ball - Heise Security
- Coming in March: Month of PHP bugs - ZDNet Blog
Use of this information constitutes acceptance for use in an AS IS condition. There are no warranties, implied or express, with regard to this information. In no event shall the author(s) be liable for any direct or indirect damages whatsoever result of or in connection with the use or spread of this information, which is distributed for educational and research purposes only. Any use of this information is at the user's own risk.