After a fairly short incubation period, 2.7.0 final is now available for download. Installation Script Upgrade Script The release was made a bit faster then anticipated in response to a rather serious security problem found in the uploaded avatar handling code. All who use FUDforum and allow forum members to upload custom avatars are encouraged to upgrade immediately. The details of the exploit are not being released at this time, but believe me when I say that the problem is quite serious and you should most definitely upgrade if you use the uploaded avatar functionality. Aside from the fix for the security problem, this release integrates a number of other changes and improvements, in particular a much improved in terms of speed forum topic view generation code. The list below inclidues the changes found in the final, that were not present in RC1. Fixed a number of edge cases where E_NOTICE warnings may be generated. Unify SQL error handling. A number of PostgreSQL fixes and computabil...

While on my daily news crawl, I came across a site (http://gdataonline.com/seekhash.php) offering a free and very quick service designed to decode md5 hashes. The principal used here is a dictionary attack; the operators of the site build a reasonably large, 12 million & counting, database of hashes and their corresponding values. All you need to do is specify a hash and if they got it in their database in less a then a second you get to see its corresponding value. While compromising weak hashes via dictionary attacks was never that hard, it did require wasting some time and processing power in application such as John the Ripper (http://www.openwall.com/john/) trying to find the equivalent value. Now, you can do it quite effectively (I’ve tried) via this online tool in fractions of a second. Given that many PHP applications (my own included) store passwords as hashes rather the clear-text, it now raises the needed to encourage users to be a bit more creative with their password strings. Use of high-ASCI...

Came across a rather “interesting” peculiarity in PHP, which affects mathematical operations involving floating point numbers. Before getting into the details, let me introduce you to the problem I was trying to help a friend solve. The goal was to take an arbitrary floating point number, let’s say 1.841243, and convert it to a whole number where decimal points became part of the whole, so 1.8432432 would become 18432432. The first solution was a very simple scriptlet, which if C has taught us anything should’ve worked. [php] $a = 1.8432432; while ((int)$a != $a) $a *= 10; [/php] This code relies on 2 premises, which are true in PHP: 1) Casting a float to an int, results in a drop of decimal points. (Ex. (int) 1.8432432 => 1) 2) By multiplying value by 10, all decimal places will eventually be gone and (float)$a will equal (int)$a. While both premises are true, the above code does not work, in fact, it results an unterminated loop, YIKES! Quick confirmation with C code, included below, re-affirms th...

Yesterday I've discovered an "interesting" implication of using user input inside var_export() and print_r() functions. To those who have never used the two, a brief overview of their functionality. The var_export() function takes a variable and represents the data found within as a valid PHP string. By default this string is dumped to screen, but if you want you can have it be returned as a string, by passing a 2nd optional parameter as boolean TRUE. For example if you wanted to put an array creation code into a file, you'd do something like this: [php] file_put_contents("my_file", var_export($array, 1)); [/php] The print_r() function is similar in function, except the returned data is intended for debugging and not storage. As with var_export() by passing a 2nd optional parameter you can force the data to be returned as a string rather then dumped to screen. Herein lies the problem, when it comes to storing the data, this is done by enabling output buffering of the content without a set buffer size limi...

About a year ago when gas prices in Canada have started to rise rapidly my friend and I were trying to guess when they will exceed the $1 per liter mark. After some discussion we've mostly agreed it would not happen till 2006 at the earliest. Alas our predictions were proven false, as the picture below shows today, August 13, 2005 the $1 mark has been surpassed. Given that $1 for a liter is a physiological marker for many people, it would be interesting to see what impact it would have on the quantity and type of cars seen on the road. Perhaps it would finally reduce the need for city dwellers to purchase giant fuel guzzling SUVs and similar type vehicles, but only time will tell. One thing's certain however, fuelling up your car will be much more of a hit on your wallet, just a month ago I could relatively easily fuel up for mere “0.80” cents a liter. A 20% increase in such a short time is highly noticeable and most unwelcome. NOTE For those of you who don't use the metric system or don't know late...