2.10 Security Advisory

Tuesday, May 9th, 2000

2.10 Security Advisory

Bugzilla Security Advisory
May 9th 2000
Author: Chris Yeh ([email protected])


Users of Bugzilla are recommended to apply the following patch or upgrade to version
2.10 of Bugzilla.


Index: CGI.pl
===================================================================
RCS file: /cvsroot/mozilla/webtools/bugzilla/CGI.pl,v
retrieving revision 1.65
diff -u -r1.65 CGI.pl
--- CGI.pl      2000/04/27 23:12:44     1.65
+++ CGI.pl      2000/05/05 04:56:24
@@ -560,6 +560,11 @@
             }
         }
     }
+    # if 'who' is passed in, verify that it's a good value
+    if ($::FORM{'who'}) {
+        my $whoid = DBname_to_id($::FORM{'who'});
+        delete $::FORM{'who'} unless $whoid;
+    }
     if (!$loginok) {
         delete $::COOKIE{"Bugzilla_login"};
     }

It is also recommended that you closely examine permissions on your Bugzilla
installation.

Make sure you are not running mysqld as root.

Included is one person's examination of their local bugzilla installation, 
and how they secured it.

----------------------------------------------------------------------------------

I closed-up some of the all-writeable files and directories. The code itself had
to be modified to keep it from making directories and files world-writeable again...

Once this was done, I felt confident that this install of bugzilla was running
securely.(We don't run ftp, and mysql doesn't run as root). 

The setup we have is that apache runs as user 'nobody'. Directories being written into
via CGI are therefore owner.group==nobody.nobody and only read/writable by user nobody,
not world-writeable as before ... The *.cgi/*.pl/etc scripts (source) are owned by
root.root and we can prevent CGI execution and HTTPD reading of the scripts by doing
chmod go-rwx.... Finally, we prevent reading of the writeable directories by HTTP.
(The security of this could further be improved by running bugzilla as user 'bugzilla'
with same privs as 'nobody' but at least a different user than the webserver).

I did the following to secure our install:

(1) cd /home/httpd/bugzilla ensure all files owned root.root (other than ones in
'shadow' and 'data').

(2) chmod go-rwx backdoor.cgi ; chmod go-rwx *.sh ; chmod go-rwx printenv.cgi ;
chmod go-rwx 0CGI.pl ; chmod go-rwx *~* ; chown -R nobody.nobody data ;
chmod -R go-rwx data ; chown -R nobody.nobody shadow ; chmod -R go-rwx shadow

(3) in emacs, in *.pl and *.cgi and processmail in bugzilla dir
(etags *.cgi *.pl processmail) ... do:

(tags-query-replace "umask 0" "umask 077" nil)
(tags-query-replace "umask(0)" "umask(077)" nil)
(tags-query-replace "0777" "0700" nil)
(tags-query-replace "0666" "0600" nil)

(4) reenable bugzilla with /home/httpd/bug-track.conf set to:
--------------------
AddHandler cgi-script .cgi

#
# setup ExecCGI'able directory alias from which we run
# "bugzilla" under URL "bugs"
#
Alias /bugs/ "/home/httpd/bugzilla/"

<Directory "/home/httpd/bugzilla">
Options Indexes ExecCGI
AllowOverride None
Order allow,deny
Allow from all
</Directory>
--------------------

(5) add to /home/httpd/bug-track.conf (prevent cgi from being
written into data or shadow directories, and prevent contents from
being read):
--------------------
<Directory "/home/httpd/bugzilla/data">
Options None
AllowOverride None
Deny from all
</Directory>

<Directory "/home/httpd/bugzilla/shadow">
Options None
AllowOverride None
Deny from all
</Directory>
--------------------

(6) I noticed that my
non-superuser-$PATH had wound up in apache's GGI
environment... that $PATH included "." so that could have been a
security-exploit-in-waiting right there... so remember, when
restarting apache on servers, do (in tcsh anyways):
unsetenv *
prior to doing
apachectl stop
<wait>
apachectl start