In the past few days I've been testing a number of my own applications and scripts as well as various bits and pieces of applications written by others that I use, using an automated scanning tool I have written. One particular issue I came across, common to all applications is the inevitable "path disclosure vulnerability". The premise behind this so called vulnerability is that remote attackers by specifying certain value can make the script report it's own location on disk. Theoretically this combined with another vulnerability could be used to do something or rather then potentially could be bad. As you can probably tell, I don't see this as a something to be terribly concerned about in most cases. To demonstrate consider the following, most PHP function that take strings as parameters, like our favorite validation functions such as htmlspecialchars(), addslashes(), and so on will raise warnings when values they are passed are arrays rather then strings. This means that to get the path of the script,...

After nearly 2 months of development FUDforum 2.6.14 is finally out. Aside from the usual bug fixes this release includes a number of important improvements, such as full support for PHP 5.1 and introduction of a PDO database driver support, which enables FUDforum to talk with SQLite in addition to MySQL and PostgreSQL. In addition to all of the changes in found in RC1 and RC2 there is a small number of modification made since then, a list of which can be found below. The installer and the upgrade script can be found at their usual locations at: http://fudforum.org/download.php and all FUDforum users are encouraged to upgrade. Post RC2 Changes A series of fixes for the PDO SQLite driver. Fixed the phpBB2 conversion script. Added the ability to clear tracker for the NNTP import. Remove pointless JavaScript header in full-body e-mail notification, that triggered some spam filters (SpamAssassin). Fixed DB detection in the installer, when only one database driver is available. Added FUD API...

It seems web hosting companies are finally coming to grips with something most security experts have known for quite some time, phpBB is inherently insecure. According to Netcraft some are taking the steps to prevent further exploitation via this application by banning its usage on their servers. As per usual phpBB developer's response, they are denying blame and claim such moves are unwarranted, but given their security record during the past 6 months alone this is hardly surprising. Not only are new issues being found, because the developers can't seem to do an security audit, but new versions re-introduce bugs (2.0.15 re-introduced the flaw exploited by Santy worm) that have previously been solved. I hope other hosting providers will take notice and adopt the same strategy, not only for phpBB2 but for any application with a consistent history of security faults for which the developers do not wish to take responsiblity for. As well as failing to take the time to conduct an extensive security audit...

The 2nd release candidate of 2.6.14 was just published; this release performs the final bit of cleanup, code rearrangement and unification to make usage of PDO as a database interface possible. As of this release it is now possible to install FUDforum with the following PDO drivers: MySQL, PostgreSQL and SQLite in addition to the native MySQL and PostgreSQL interfaces. Other important changes include fixes that accommodate the PHP 5.1 backwards compatibility (BC) breaks introduced after 5.1.0b1. Also, FUDforum no longer requires temporary tables, making their use optional, which should be welcome news to all the people who don't have the necessary privileges to perform this operation. The installer and upgrade script are now available online and can be downloaded from: http://fudforum.org/download.php The release also includes various minor fixes and improvements, listed below. Properly recognize permanent bans on ban list admin control panel. thread_view table is now forced to MyISAM for MySQL....

PHP 5.1 is well on its way towards release, so very little time is left to sneak in forgotten or missing features into it. One very handy (IMHO) feature that I've added to the PDO MySQL driver is the ability to toggle usage of buffered queries. Up until now any query executed would be unbuffered, which limited you to operation with just a single result cursor at a time. The only way to avoid this limitation was to use fetchALL() method to pre-fetch results into array and then use them. This however is not always possible or practical as I've found out in the progress of adding PDO support to FUDforum. So, what do you do when something is lacking in PHP? Write a patch of course! As of yesterday you can set PDO_MYSQL_ATTR_USE_BUFFERED_QUERY attribute to TRUE to enable buffered queries and FALSE to disable them. [php] $a = new PDO($dsn, $login, $passwd); $a->setAttribute(PDO_MYSQL_ATTR_USE_BUFFERED_QUERY, 1); $res = $a->query("SELECT ..."); $a->setAttribute(PDO_MYSQL_ATTR_USE_BUFFERED_QUERY, 0); foreach...