[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [eclipse.org-committers] More about the Bugzilla & website outage of yesterday
|
Balancing security vs. functionality is a difficult game. We'd like to
give you all the tools you need, make them easy-to-use, while
maintaining a decent level of security. However, in light of this
event, we have done (or will be doing) the following changes in the
weeks to come:
1. better monitoring of possible probes.
In addition to our current monitoring of other services, we'll be
actively monitoring URLs for suspicious activity.
2. tightening down PHP
Our default PHP config is quite open (as you can see) and that needs to
change. We will be limiting PHP file access to, and only to, the Website
directory (/home/data/httpd/). Any file access attempt outside of that
realm will fail. Some of your (and my) PHP code may break as a result of
this - but we shouldn't be opening URLs or files from outside of that
space anyway. This will also disable executing system() functions.
As it stands, we cannot afford to not do this.
3. resetting RSA keys regularly
Some committers, myself included, prefer to use RSA public/private key
authentication instead of passwords. Although we expire passwords every
six months, we never require you to regenerate new keys. We will be
deleting SSH keys regularly (and don't think of reusing the old one -
we'll keep track).
4. more aggressive with login attempts
Although we currently monitor and block the quasi-daily SSH attacks and
brute-force attempts, we'll be expanding our efforts to ensure our
monitoring and blocking is more efficient.
5. more conservative with the software we run on eclipse.org
Some folks think we can "just install package X" on the website. It's
not that simple, and now it just got even more complicated.
What can you do to help?
1. write good PHP code
Although we don't consider ourselves expert PHP coders, if you're unsure
about what you wrote, as us to have a quick look - we can find potential
security holes quickly enough.
2. if your laptop or computer have been stolen or compromised, tell us.
You may have saved your committer password in Eclipse, or you have a
private key that can be used to gain local access to our systems.
3. safeguard your password
If you have any questions, please feel free to e-mail me directly.
Thanks,
Denis
Bjorn Freeman-Benson wrote:
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:
...header...
output_file( $_GET['page'] )
...footer...
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.
- Bjorn
------------------------------------------------------------------------
_______________________________________________
eclipse.org-committers mailing list
eclipse.org-committers@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-committers
--
Eclipse WebMaster - webmaster@xxxxxxxxxxx
Questions? Consult the WebMaster FAQ at
http://wiki.eclipse.org/index.php/Webmaster_FAQ
View my status at http://wiki.eclipse.org/index.php/WebMaster
