|[eclipse.org-committers] More about the Bugzilla & website outage of yesterday|
To: Committers Who Feel Like Reading About The Nitty-Gritty Details,|
In late Febuary 2005 (almost a year ago), one of the BIRT committers created a nice BIRT website. The website had a home-brew content managment system that worked by having a single dispatcher file (index.php) that took as a parameter the filename of the page to display in the body. index.php than wrapped that page file with the header, menus, etc. The code looked something like this:
output_file( $_GET['page'] )
Unfortunately, as you can see, there was no checking on the filename passed in via the page parameter. Thus an attacker could call http://www.eclipse.org/birt/index.php?page=/etc/passwd (or, the way they actually did it was: http://www.eclipse.org/birt/index.php?page=../../../../../../../../../../../../../../etc/passwd). This was bad.
I'm not sure what suspicious behavior Denis noticed, but when he saw it, he shut down the BIRT website and Bugzilla in order to investigate and recover. He had to look through eleven months of logs to see what had been compromised and he discovered a number of passwords across the website, including passwords to the internal database, that were compromised. So then Denis had to see if any trojans had been planted or data corrupted, etc.
Consequently, this security error affected everyone on the eclipse.org servers, not just the offending project.
In addition, the guilty project had recently done a major release and the fact that their website was down caused them some stress vis a vis press people and users wanting to download the new release.
Now, I'm not writing this email to embarrass any particular person, and I request that this information not be blogged or published - thank you. Once everyone figured out what was going on, many people worked very hard to fix the damage and to fix the hole in a permanent way.
However I am putting all the details in this email so that the rest of us (committers) can learn from this mistake. It's a well-known security rule to never trust the user input. Perl even has a nice language construct (taint) to deal with this issue (PHP does not appear to have a taint mode). Please put checks, filters, and rules on all user input in your PHP files. (And, as we move to a completely PHP-driven website using Phoenix, this is doubly important.)
Thanks again to Denis for his extra hours in finding, limiting, and then recovering from this issue.