Bogdan Calin reported a deficiency in the way PHP used to handle form-based file uploads. A remote attacker could cause Apache web server denial of service (httpd collapses and gets unresponsive) by submitting a PHP file upload request encompassing enormous (15000+) number of files. References: ----------- [1] http://seclists.org/fulldisclosure/2009/Nov/228 [2] http://bugs.gentoo.org/show_bug.cgi?id=293888
This issue affects the versions of the php package, as shipped with Red Hat Enteprise Linux 3, 4, and 5. This issue affects the versions of the php package, as shipped with Fedora release of 10, 11, and 12.
This is CVE-2009-4017: ---------------------- PHP 5.2.11, and 5.3.x before 5.3.1, does not restrict the number of temporary files created when handling a multipart/form-data POST request, which allows remote attackers to cause a denial of service (resource exhaustion), and makes it easier for remote attackers to exploit local file inclusion vulnerabilities, via multiple requests, related to lack of support for the max_file_uploads directive.
Upstream commits: http://svn.php.net/viewvc?view=revision&revision=289990 http://svn.php.net/viewvc?view=revision&revision=290029
This problem can be used as part of the DoS attack where PHP creates lots of temporary files to store content of the files being uploaded. If attacker can generate enough concurrent POST requests with large number of uploaded files, large number of temporary files will slow up creations of additional temporary files resulting in increasing system load. As noted in the original report, this can be avoided by disabling handling of file uploads if they are not needed using file_uploads option in php.ini. file_uploads setting is on by default. If file uploads are needed, reducing maximum POST body size can help mitigate this flaw. That can be done via PHP's post_max_size configuration option (default of 8M) or httpd's LimitRequestBody directive (unlimited by default). This should be used with care as the limit needs to be higher than what is needed for legitimate POSTs. Attacker needs about 70 bytes in request per file, so even 1M post_max_size limit allows lot more than 10000 files per request. Limiting number of connections / request per IP and other DoS protections can help here too.
Public reproducer: http://www.paste-it.com/view/77958658 pointed out by Moritz Naumann on full-disclosure list: http://seclists.org/fulldisclosure/2009/Nov/262
php-pear-Mail-1.1.14-5.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/php-pear-Mail-1.1.14-5.fc12
php-pear-Mail-1.1.14-5.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/php-pear-Mail-1.1.14-5.fc11
php-pear-Mail-1.1.14-5.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/php-pear-Mail-1.1.14-5.fc10
Will there be a fix for Red Hat Enteprise Linux 3, 4, and 5?
(In reply to comment #18) > Will there be a fix for Red Hat Enteprise Linux 3, 4, and 5? max_file_uploads is planned to be introduced in the upcoming PHP updates for all supported Red Hat Enterprise Linux versions.
This issue has been addressed in following products: Red Hat Enterprise Linux 5 Red Hat Enterprise Linux 4 Red Hat Enterprise Linux 3 Via RHSA-2010:0040 https://rhn.redhat.com/errata/RHSA-2010-0040.html
php-5.2.12-1.fc11, maniadrive-1.2-17.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.