Blog customization, old PHP advisories

Today, I would like to post a less-technical text, discussing two issues I have recently came across, or been busy with; don’t worry though, as CSRSS Write-Up: IPC (part 2/3) is on the way. The first matter is about recent changes applied to the blog appearance and functionality, while the latter regards the results of a source-code audit performed by me and my Hispasec colleagues (Gynvael Coldwind and Icewall) something like a year ago (last summer :-)).

As you must have already noticed (unless using a RSS reader), the monolithic, light blue (otherwise known as cyan) background color has been replaced with a  stylish, purple image sized 1680 x 1260. Due to the fact that I’ve been encountering some major compatibility problems (scroll-lagging, incompatibility with certain browsers), the picture does not cover the entire area in case a higher resolution is used. Should you experience any problems (e.g. wrong rendering) with the current appearance, please let me know ASAP (specifying the browser name/version by the way). Comments with opinions regarding the current style are also welcome! Furthermore, I decided to make use of the “display summary” setting, so that the latest post entries are printed in a shortened form, instead of flooding the screen with entire contents. The behavior applies to other functionalities, such as the search engine, as well. Hopefully, this will improve the general blog readability :-)

As for the second part of the post – a few days ago, I have recalled of a small, experimental research performed by the HSPL team roughly a year ago. Having the The Art of Software Testing (by Glenford J. Myers) book read, we decided to try one of the presented code auditing approaches in practice, on real software. As it was closely related to the vulnerability-hunting subject, a popular, yet open-source project was about to be focused on. After a few minutes of live discussion, it became clear that the target would be none other than PHP! (or more precisely, one of its default extensions, such as php_exif).

The general idea behind the auditing technique is fairly simple – once the adequate number of copies of the target source code is printed on a piece of paper (i.e. one for each person taking part), one of the participants starts reading the source code aloud, line by line, starting from the attacker’s entry point (like an exported routine, available to the .php script). In the meantime, the rest of the team exchanges their thoughts and tries to think of every possible inconsistency in the current code row – when one is found, the general analysis is suspended for the time of testing a potential vulnerability. If a function call is encountered, the execution position is written down on some paper, and the analysis is continued from the beginning of the new routine. What’s more, the technique could be employed with a monitor together with a text-editor fired up (making some of the activities much easier), as well; the choice is up to your crew.

The actual efficiency is obviously different for various projects – keep in mind that every open-source application follows its own set of coding / security rules and possibly imposes certain types of security flaws. Besides, I highly recommend every bug-hunter to make an effort and test this approach on himself – it is a very informative experience, in my opinion. When it comes to our results,  we ended up with three different ways of crashing the latest (at the time of the research) version of PHP on every software platform, plus another three minor memory disclosure flaws. All of these were related to image format parsing (TIFF and JPEG) functionalities. After sending the explanatory advisories to the PHP devs, the bugs were eventually fixed – however, no real credit has been given to our work. Shit happens.

If you are highly interested in the PHP engine/extension code quality, feel free to take a look at the provided advisory documents.

A complete package, containing a bunch of short, technical papers (there are six in total) can be found here (ZIP, 11kB).
Sorry for not providing the PoCs – these are way too dirty to see the public light :-)

So… that’s it! Have fun reading the docs, necessarily leave a comment on the blog appearance and… see you in a next post!