Software Security/Group 1/Log

Log

Date	Activity	By
March 18	Formed group and picked subject	Wouter,Boy,Bob
March 25	Formed group with Eelis	All
April 01	Downloading code, setting up Fortify	All
April 01	Running and analysing Fortify	Eelis,Wouter
April 01	Setting up apache + phpbb	Bob,Wouter
April 01	Writing code to extract php from templates	Bob,Boy
April 01	Setting up and running CodeScan	Boy
April 01	Resolving php+phpbb compatiblity issues	Boy
April 08	Discuss the results	Eelis,Boy,Bob
April 08	Running Fortify with php from templates, mailing the results	Eelis
April 21	Mailing Fortify results	Eelis
April 21	Proof-reading log and comparison	Bob,Wouter
April 22	Report on CodeScan	Boy
May 20	Manual verification	Wouter,Eelis,Boy,Bob
June 7	Manual verification	Wouter,Eelis,Boy,Bob
June 10	Manual verification	Wouter,Eelis,Boy,Bob
June 17	Manual verification	Wouter,Eelis,Boy,Bob
June 20	Prepare presentation	Wouter,Eelis,Boy,Bob

More elaborate description including the struggles:

1 April 2011

While running Fortify on a single source file (viewtopic.php) works, running it on a whole bunch of PHP files at once is proving more problematic. Running Fortify only on individual files one at a time doesn't seem very useful, because Fortify typically needs to see code paths through multiple files to diagnose issues. Initial attempts to do a full scan caused Fortify to run out of memory, resulting in a /partial/ results data file (which nevertheless enumerated over 6000 issues, several of which (such as the XSS vulnerabilities) do appear relevant to us). We are currently re-running Fortify with more memory to get a complete results data file. Update: with more memory, Fortify ran to completion (in one hour), but the results seem to be about the same.

We have briefly reviewed parts of the phpBB2 source code related to output (our chosen subject). phpBB2 apparently uses a template approach whereby an almost-HTML .tpl file is parsed for special variable substitution and iteration directions, "compiled" into PHP code, which is then eval()'d. We fear that this indirection with dynamic code generation may make it very hard to use static source code analysis tools to analyze the code, because the eval()'d code isn't determined until runtime.

In order to subject this runtime-generated code to analysis, we have done a preliminary phpBB2 install on a development machine, and changed it to dump the generated PHP code to a file just prior to the eval() call. This kinda works (a little bit), but because this phpBB2 install is 90% broken (because it is not really compatible with contemporary PHP versions), we can't really see as much as we'd like to. We are working on compiling an older PHP, so that we may get a fully functional phpBB2 install going.

We have managed to get the CodeScan tool running (only on Windows, all attempts to run it on Linux have failed). One annoying obstacle was caused by phpBB's practice of using concatenated strings in include directives. Still, after working around this issue, we got CodeScan to produce a list of 1029 issues.

We now have issue lists from both Fortify and CodeScan, which we will review next time.

8 April 2011

With some effort, we managed to set up a proper phpBB install, and have used it to run once more the instrumented code that dumps into files the PHP output generation code passed to eval(). We have added these dumped files to a subdirectory in the phpBB source code directory, and have re-run Fortify with this added code, hoping that it might diagnose more issues, now that it can "see" more code. This hope might be in vain, though, because the dumped output generation code is not actually invoked through normal PHP function calls (but rather through eval()), and does not contain any include-directives, so it remains to be seen whether Fortify can relate it to the rest of the code base.

20 May 2011

We managed to find two security issues. Both are not directly HTML-injection, but both can lead to one. We found that most obvious data is HTML-encoded upon saving it in the database. When reading from the database, no checks were done. This meant that any SQL-injection could also lead to HTML-injection. The first error we found was a non-validated query-value which was used in a SQL-query. This could be used to inject the database with HTML/Javascript, which later would be send to all clients as-is. Another error we found was that smiley-image-urls were not validated and therefore were send directly to the client. This could be used to exit the <img> tag with '">' and add malicious HTML code. However, smileys could only be added by moderators of the forums. This leads us to the next error we found. The forms in phpBB post data to a 'action'-url. Most of these action-urls in phpBB can be called directly, including all parameters. This means that one can add smileys by just typing a certain url in the addressbar, or clicking on a link that contains such a url. Such a link could be placed on any webpage, including the forum itself. This means that one can post an url to let other users on the forums do something unwillingly when they click on the link. Even worse is that this also applies to moderators clicking that link. This could for example be used to let an moderator add a smiley to the database, which in turn contains malicious HTML-code, which in turn is send directly to all users that view a post with such a smiley (like :D, or even a text like 'hello' could be converted to a smiley). Indirectly this can be used to do massive html-injections, which reach all users on the forums on almost all posts. All in all this was a productive day, though we have not found a major issue that could be -directly- used for HTML-injection. The above HTML-injections were only possible because of other (non-HTML-related) errors in the code.