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/
