www.hardened-php.net/documentation.php
In 2002 a few people from OpenBSD users created the PHP auditing project after I released my advisories aboute remote holes in PHP. It seemed quite uncoordinated and the people all lost their interest because they never found anything. In the months since then I found several remote vulnerabilities in PHP before they could make it into a release version. However the codebase is quite large and therefore I decided to create Hardened-PHP. The project was pulled back several times because of lack of time. This was until the 17th of April 2004 when I released the first version of Hardened-PHP which had already most of the features wanted for the first step. This was bringing some visitors to the page which was infact a ugly page with nearly no information, and no documentation. A month later at the 16th May 2004 the website was redesigned. Additionally this document was released in its first version to have a basic documentation. On the same day the Hardened-PHP 011 was released with just some small fixes for PHP and the patch itself.
php After downloading the tarball into your temporary installation directory (fe /home/install) it is recommended that you check the md5sum of the file before you continue. patch From here follow the PHP manual howto install it ony your platform.
This function is a wrapperfunction for malloc() which implements (beside some things like a cache for small blocks) a double linked list of allocated memory blocks. This list is needed to free all allocated memory at the end of request. zend_mem_header emalloc() allocates more memory than requested because 31 30 0 it has to add 3 header fields +-----------------+ to the beginning of the block | p P r e v | +-----------------+ It should be obvious that an | p N e x t | overflow into this memory +---+-------------+ will first overwrite the | C + s i z e | pPrev and pNext fields which +---+-------------+ <--- returned are the forward and backward | | pointer pointers in the linked list | | of allocated memory block. In both | | cases the block is taken off | | linked list. p->pPrev->pNext = p->pNext AND p->pNext->pPrev = p->pPrev This allows to overwrite nearly arbitrary addresses with nearly arbitrary values if you control p->pPrev and p->pNext, which can lead to a code execution exploit. When Hardened-PHP is activated it will add so called canaries to the beginning and the end of each allocated block. These canaries are no birds but 32bit wide values which are randomly generated when the memory manager is started. Whenever the block is reallocated or freed the memory manager will check if the canary values have changed. This is sufficient to protect the unlink operations because an attacker cannot guess the random values. Hardened-PHP uses 2 canaries because this protects against an overflow into emalloc()ed memory AND against an overflow out of such a block. Important: It is necessary to know that 3rd party libraries used by PHP will NOT use emalloc() but malloc() directly. This means that heap overflows could be still exploitable under some conditions. But this check is good enough to ensure that it is not the PHP memory that is abused to execute arbitrary code, which is good news because some libc versions have very hard/or impossible to exploit implementations of malloc(). On those systems heap overflows in PHP would be easily exploitable if Hardened-PHP is not activated.
These lists have a structure which is also very vulnerable to overflows. If an attacker would be able cause PHP to overflow a part of memory that contains a linked list descriptor structure it would be possible to overwrite the stored pointer to the linked list dtor() with a pointer to any memory address. This would allow code execution when the list is destructed. Hardened-PHP adds canaries in front of the list descriptor structure to protect it against an overflow. Additionally a canary is added to the end because sometimes the descriptors are stored in stack and the overflow would come from the other side. Because linked list elements are always in heap they only get a prefixed canary. Whenever an operation is performed on the linked list descriptor or one of its elements the canaries will get checked and when an overflow is detected the script will be aborted.
This is because the %n specifier allows to write any values to arbitrary memory addresses. PHP comes with its own implementation of snprintf() and a memory self allocating variant spprintf(). Both functions implement the %n specifier which is not uses at all within PHP. Hardened-PHP when activated removes the %n specifier from the internal snprintf() and spprintf() functions. Additionally a macro is set to replace all calls to the libc snprintf() with the PHP own version. This means, that if someone adds a format string bug to PHP in the future, it won't be exploitable.
This is done at execution time and even allows to include files on remote systems, which can become a huge security risk if the include statements are not protected in a proper way. Actually this is the most often used entrypoint of hackers when they succeed in hacking a site running a vulnerable PHP script. Hardened-PHP includes countermeasures for the most often seen mistakes.
aktion=/etc/passwd to see your password file in his browser. It is obvious that an attacker who knows a way to embed PHP code into a file on your server will be able to execute it through this statement. What is maybe new to any PHP beginner is that there is a feature called fopen_wrappers which allows to include a file from a remote system. It is more than obvious that this feature can be a great security risk for any site that runs code written by PHP beginners but disabling this feature could also be a bad idea. This is because PHP does not allow to disable remote includes separately from remote file support for the other file access functions. If Hardened-PHP is activated it will disallow any include filename that looks like an URL and will log the attempt to syslog. Any URL is maybe to strict and will be relaxed in a future version. The strict rule is the reason why the fopencookie() regression test fails when Hardened-PHP is running.
This can be used if fopen_wrappers is turned off but register_globals and file_uploads are turned on. In such a situation it is suffient to perform a post fileupload to the vulnerable script with aktion as name of the file variable. Because register_globals is turned on the variable $aktion will contain the temporary filename of the uploaded file. Of course this can contain arbitrary PHP code that would get executed under this circumstances. Hardened-PHP will stop such attacks because it does not allow including an uploaded file.
While this maybe is true he forgets (or simply does not know) that PHP strings are binary safe, which means that anywhere within the userinput could be an ascii NUL char. If they differ the file is not included and the attack is logged.
This is done because it doesn't add much overhead (for string cut protection we need strlen() anyway), but could protect against bufferoverflow attacks on the underlying filesystem functions. If a filename triggers this check it will be logged to syslog.
This is not caused by a bug within the implementation but by design of the include() protection feature. At the time of writing this document Hardened-PHP simply forbids all stream includes to protect against remote file inclusion. Without this feature the fopencookie() test cannot work and therefore fails. Future versions of Hardened-PHP will partly restore stream inclusion support, to work around this limitation.
When writing to this address please include the string Hardened-PHP in the subject line due to the amount of spam. You can use this address also to donate money to the project via Paypal.
|
http://csua.com/feed/