Greg Freeman has posted the second part of his "hacked PHP application" series (part one is here). In this new post he looks at the aftermath - what to do and check to do cleanup and fixes so it doesn't happen again.

This is a follow up post from my previous post "How to Tell if Your PHP Site has been Hacked or Compromised". This post will discuss some the first steps you should take when you have identified that your site has been compromised. The first sections discuss a few points that are not relevant to everyone, the later sections will discuss how to fix the exploits.

He includes a list of things to think about including:

• What kind of hosting you use (and if that contributed)
• The option to redirect all requests for your site to one page
• Get a list of all PHP files to locate something malicious
• Locating "non-PHP PHP files"
• Finding files with possible malicious content

He also includes a few suggestions to help prevent issues in the future - update to the latest versions, patch your code, rethinking your permissions and monitoring for potential repeat attacks.

Davey Shafik has a recent post to his blog about what he calls "The Blowfish Debacle" - the issues that came up with the PHP 5.3.7 release to upgrade the crypt_blowfish version that resulted in a larger error being introduced.

This was a great security fix, solving an issue with insecure passwords due to incorrect behavior. HOWEVER, what wasn't made clear, is that this change was actually a backwards compatibility break. If you upgraded to 5.3.7+ data hashed pre-5.3.7 would no longer match data hashed post-5.3.7; this means if you use it for passwords, it will no longer match. So what's the deal here?

He talks about the differences in the two methods of encryption, the newer being the "more correct" way of doing things. If you need the backwards compatibility because of previously hashed values, you can use the "$2x$" prefix instead of the usual "$2a$". He includes a snippet of code that can be used to upgrade all of your previously hashed blowfish passwords up to the new format.

The PHP development team has officially announced the release of the latest version of PHP in the 5.3.x series - PHP 5.3.10:

The PHP development team would like to announce the immediate availability of PHP 5.3.10. This release delivers a critical security fix. [...] Fixed arbitrary remote code execution vulnerability reported by Stefan Esser, CVE-2012-0830.

It is highly recommended that users upgrade to this latest version to avoid falling victim to this recently introduced bug relating to the new "max_input_vars" setting added to protect from the overflow issue recently brought up in the PHP community.

Chris Hartjes ran into an issue with hit unit tests where PHPUnit was throwing an "aborted" error no matter what tests were run. Thankfully, in this new post, he shares a solution.

That was a pretty annoying bug. I never did find out what the problem was as I moved onto other problems and chalked that error up to some undiagnosed weirdness on that particular server. From time to time I would get asked on Twitter if I had ever solved the problem. My answer was always "no, and if you do solve it please let met know how you fixed it." Today, my friends, was the day.

Based on a response from Demian Katz, he was able to get around the issue with flag set on the PHPUnit command line - "-dzend.enable_gc=0". Apparently the issue has to do with garbage collection and has been a known issue since the beginning of 2011.

Fabien Potencier (of the Symfony framework project) has posted the results of a security audit that was performed on the framework by SektionEins.

The Symfony2 core team takes security issues very seriously; we have a dedicated procedure to report such issues, and the framework itself tries to give the developer all the features needed to secure his code easily. Thanks to our successful community donation drive, SektionEins performed a security audit on the Symfony2 code earlier this year. The audit is now over and the good news is that the Symfony2 code is pretty solid; only minor problems have been found. They have all been addressed now

Their findings included things like the Request component trusting certain headers, bad regex validation on datetimes, password encoding issues, cookie handling and exception handling issues. Links to the fixes for each are included in the post.

Tibo Beijen has a new post today showing his method for fixing mysqldump on Zend Server CE running on an OS X platform. The default install throws a socket error when you try to dump a database using the command.

Inspecting the mysql configuration contained in /usr/local/zend/mysql/data/my.cnf confirmed that the section [client] showed the socket as returned by executing SHOW VARIABLES; from the mysql client: /usr/local/zend/mysql/tmp/mysql.sock Although it is possible to specify the socket by using mysqldump's --socket switch, that doesn't really seem a 'solution'.

As a real solution to the problem was to copy over the my.cnf file from the custom location Zend Server has it in to the default "/etc/my.cnf" with settings pointing to the correct MySQL socket.

Matt Williams has a new post to his blog with his own fix to a problem he was having with his CodeIgniter application - the continuous session logouts.

For weeks I tolerated the annoyance of CodeIgniter's Session library logging my out continuously, saying to myself "I works...kind of...I'll fix it later". Eventually the problem started affecting AJAX method calls, large file uploads and simple CRUD operation forms so I began trawling the internet for a fix. After hours and hours, I found that there was no _reliable_ fix to the database sessions library and that the answer was, DON'T USE DATABASES.

The code for the library he found to help with the problem - CI_Native_Session - is included in the post (as written by Dariusz Debowczyk). It uses the native PHP session handling to keep track of the data rather than using a database table to persist users. You can see a demo of it here.

On the Zend Developer Zone there's a new post announcing the latest Bug Hunt Days for the Zend Framework happening this week - Thursday, July 15th through Sunday, July 19th.

For those of you unfamiliar with the event, each month, we organize the community to help reduce the number of open issues reported against the framework. The last two months of bug hunts collectively closed 63 issues. The May bug hunt saw new first-time winner Jan Pieper step up and take first. Then in June, Christian Albrecht (a previous bug hunt winner) took home first again. Congratulations Jan & Christian and thanks for making the bug hunt for May and June a success.

If you'd like to get involved, you'll need to have a CLA with Zend approved and ready to go. Then just show up on the #zftalk.dev channel on the Freenode IRC network and jump right in. There's also a guide to help you get started as well.

On his IIS.net blog Don Raman is asking for help in testing Microsoft's WinCache caching tool because of a critical fix they had to make to the current version.

There has been several instances where people using WINCACHE have reported problem while running it on the actual production server. They have complained that WINCACHE works very well on development server but the users can see a crash (or different symptoms of it) while actually deploying it on a live production server.

There have been several reports of the issue where the site visitor gets an empty page back and WinCache will crash. For those wanting to get into the technical details, the post includes them or, if you just want to find out more about the bug, there's a few email addresses you can contact the WinCache team at.

In a new post to his blog Michelangelo van Dam reminds developers everywhere about the Zend Framework "Bug Hunt Day" effort to make the framework an even better tool to develop applications.

Last week Thursday the start was given to Zend Framework's Bughuntday and it turned out to be a huge success, as mentioned by Chief Architect Matthew Weier O'Phinney on Zend's DevZone website. Over a hunderd bugs were squashed leading up to the release of Zend Framework 1.9.3.

He talks a bit about what the goal of the Bug Hunt Days are all about and a few ways you can help by closing out some of the bugs marked open in the Issue Tracker.