From 292e003a74f115e2c7f609a3952f8638d631808d Mon Sep 17 00:00:00 2001 From: "timeless%mozdev.org" <> Date: Fri, 4 Apr 2008 11:48:09 +0000 Subject: Bug 345970 Avoid using the string 'the web' patch by jhulten@tragicallyleet.com r=timeless I've updated it to trunk r=lpsolit a=lpsolit --- docs/en/xml/security.xml | 116 +++++++++++++++++++---------------------------- 1 file changed, 47 insertions(+), 69 deletions(-) (limited to 'docs/en/xml/security.xml') diff --git a/docs/en/xml/security.xml b/docs/en/xml/security.xml index a3b9e4fe3..4842d3ebe 100644 --- a/docs/en/xml/security.xml +++ b/docs/en/xml/security.xml @@ -1,5 +1,5 @@ - + Bugzilla Security @@ -49,15 +49,15 @@ SYSTEM introduces obvious security concerns, the problems introduced by running everything as nobody may not be so obvious. Basically, if you run every daemon as - nobody and one of them gets comprimised it can - comprimise every other daemon running as nobody on your + nobody and one of them gets compromised it can + compromise every other daemon running as nobody on your machine. For this reason, it is recommended that you create a user account for each daemon. You will need to set the option - in localconfig to the group your webserver runs + in localconfig to the group your web server runs as. This will allow ./checksetup.pl to set file permissions on Unix systems so that nothing is world-writable. @@ -68,12 +68,13 @@
The <filename>chroot</filename> Jail - If your system supports it, you may wish to consider running - Bugzilla inside of a chroot jail. This option - provides unpresidented security by restricting anything running - inside the jail from accessing any information outside of it. If you - wish to use this option, please consult the documentation that came - with your system. + + If your system supports it, you may wish to consider running + Bugzilla inside of a chroot jail. This option + provides unprecedented security by restricting anything running + inside the jail from accessing any information outside of it. If you + wish to use this option, please consult the documentation that came + with your system.
@@ -89,7 +90,7 @@ The MySQL System Account As mentioned in , the MySQL - daemon should run as a non-privleged, unique user. Be sure to consult + daemon should run as a non-privileged, unique user. Be sure to consult the MySQL documentation or the documentation that came with your system for instructions. @@ -136,32 +137,25 @@
Network Access - If MySQL and your webserver both run on the same machine and you + If MySQL and your web server both run on the same machine and you have no other reason to access MySQL remotely, then you should disable the network access. This, along with the suggestion in , will help protect your system from - any remote vulnerabilites in MySQL. This is done using different - methods in MySQL versions 3 and 4. + any remote vulnerabilities in MySQL. - - Disabling Networking in MySQL 3.x + + Disabling Networking in MySQL - Simply enter the following in /etc/my.conf: + Simply enter the following in /etc/my.cnf: -[myslqd] +[mysqld] # Prevent network access to MySQL. skip-networking - - Disabling Networking in MySQL 4.x - - There's a bug in Bugzilla about this - -
@@ -177,20 +171,19 @@ skip-networking
- Webserver + Web server
Disabling Remote Access to Bugzilla Configuration Files - There are many files that are placed in the Bugzilla directory - area that should not be accessable from the web. Because of the way - Bugzilla is currently layed out, the list of what should and should not - be accessible is rather complicated. A new installation method is - currently in the works which should solve this by allowing files that - shouldn't be accessible from the web to be placed in a directory outside - the webroot. See - bug 44659 - for more information. + + There are many files that are placed in the Bugzilla directory + area that should not be accessible from the web server. Because of the way + Bugzilla is currently layed out, the list of what should and should not + be accessible is rather complicated. A quick way is to run + testserver.pl to check if your web server serves + Bugzilla files as expected. If not, you may want to follow the few + steps below. @@ -210,15 +203,6 @@ skip-networking *.pl *localconfig* - runtests.sh - - - - - But allow: - - localconfig.js - localconfig.rdf @@ -308,23 +292,19 @@ skip-networking Be sure to test that data that should not be accessed remotely is - properly blocked. Of particular intrest is the localconfig file which + properly blocked. Of particular interest is the localconfig file which contains your database password. Also, be aware that many editors create temporary and backup files in the working directory and that - those should also not be accessable. For more information, see + those should also not be accessible. For more information, see bug 186383 or Bugtraq ID 6501. - To test, simply point your web browser at the file; for example, to - test mozilla.org's installation, we'd try to access - . You should get - a 403 Forbidden - error. + To test, simply run testserver.pl, as said above. Be sure to check for instructions - specific to the webserver you use. + specific to the web server you use. @@ -367,27 +347,25 @@ skip-networking
Prevent users injecting malicious Javascript - It is possible for a Bugzilla user to take advantage of character - set encoding ambiguities to inject HTML into Bugzilla comments. This - could include malicious scripts. - Due to internationalization concerns, we are unable to - incorporate by default the code changes suggested by + If you installed Bugzilla version 2.22 or later from scratch, + then the utf8 parameter is switched on by default. + This makes Bugzilla explicitly set the character encoding, following the - CERT advisory on this issue. - If your installation is for an English speaking audience only, making the - change in will prevent - this problem. + url="http://www.cert.org/tech_tips/malicious_code_mitigation.html#3">a + CERT advisory recommending exactly this. + The following therefore does not apply to you; just keep + utf8 turned on. - - Locate the following line in - Bugzilla/CGI.pm: - $self->charset(''); - and change it to: - $self->charset('ISO-8859-1'); - - + If you've upgraded from an older version, then it may be possible + for a Bugzilla user to take advantage of character set encoding + ambiguities to inject HTML into Bugzilla comments. + This could include malicious scripts. + This is because due to internationalization concerns, we are unable to + turn the utf8 parameter on by default for upgraded + installations. + Turning it on manually will prevent this problem. +
-- cgit v1.2.3-24-g4f1b