Last Comment Bug 703975 - (CVE-2011-3668) CSRF vulnerability in post_bug.cgi allows possible unauthorized bug creation
(CVE-2011-3668)
: CSRF vulnerability in post_bug.cgi allows possible unauthorized bug creation
Status: RESOLVED FIXED
[infrasec:csrf][ws:high]
:
Product: Bugzilla
Classification: Server Software
Component: Creating/Changing Bugs (show other bugs)
: 2.10
: All All
: -- normal (vote)
: Bugzilla 4.2
Assigned To: Frédéric Buclin
: default-qa
Mentors:
Depends on:
Blocks: 835424 704308 713348
  Show dependency treegraph
 
Reported: 2011-11-20 04:50 PST by Mario Gomes
Modified: 2014-06-26 13:56 PDT (History)
10 users (show)
LpSolit: approval+
LpSolit: approval4.2+
LpSolit: blocking4.2+
rforbes: sec‑bounty+
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
POC.html (1.32 KB, text/plain)
2011-11-20 04:50 PST, Mario Gomes
no flags Details
patch, v1 (4.94 KB, patch)
2011-11-20 06:21 PST, Frédéric Buclin
mkanat: review+
Details | Diff | Review
Proof of concept File to reproduce the vulnerability(Using http://landfill.bugzilla.org) (1.23 KB, text/html)
2011-11-21 12:24 PST, Mario Gomes
no flags Details

Description Mario Gomes 2011-11-20 04:50:51 PST
Created attachment 575736 [details]
POC.html

User Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/535.2 (KHTML, like Gecko) Chrome/15.0.874.121 Safari/535.2

Steps to reproduce:

Hello Mozilla Security Team

There is a CSRF vulnerability in the page to send bugs in Bugzilla. When the value "token" is not sent on a "REQUEST" bugzilla does not process correctly, allowing the creation of the bug, with the simple interaction of the User to open a specially crafted page.

Reproduce:
1. Log in Bugzilla
2. Open repro.html
2. See your bug created


Regards,
Mario


Actual results:

The server does not process correctly bugzilla REQUEST and allows for the creation of the exploration bug.


Expected results:

The creation of User BUG without knowing it.
Comment 1 Frédéric Buclin 2011-11-20 05:06:19 PST
This is so by design. When fixing bug 26257, we estimated that unintentionally filing invalid bugs was much less critical than editing existing bugs, because in this last case, you could forge the URL to make a power user unintentionally remove the group restrictions on a valid security bug. An attacker doesn't need a power user to file invalid bugs. He can create a fake account and spam Bugzilla himself, if that's his goal.

This is still a valid request, but not a security bug, and not something we would take on branches.
Comment 2 Frédéric Buclin 2011-11-20 05:20:35 PST
Despite not being a security bug, you force me to leave this bug restricted to limit users who can access your attachment. Simply editing details of this attachment (e.g. to mark it as private) would trigger the creation of a new bug. The next time you attach a POC, please don't use a production installation as your target.
Comment 3 Frédéric Buclin 2011-11-20 06:21:54 PST
Created attachment 575741 [details] [diff] [review]
patch, v1

I partially reverted what has been implemented in bug 42946 to use our standard way to validate tokens. This change also forces a token to be present, meaning that automatic scripts will now have to pass a valid token in order to submit a new bug, or use WebServices, which is fully functional since Bugzilla 4.0.

I also added a missing delete_token() in process_bug.cgi when doing mass-change. Else this token could be reused to resubmit changes.
Comment 5 Michael Coates [:mcoates] (acct no longer active) 2011-11-21 10:26:34 PST
I'm not sure I'm correctly understanding the comments.  Is this a valid issue? If I open the attachment when I'm authenticated will it cause me to file an arbitrary bugzilla bug with my account?
Comment 6 Reed Loden [:reed] (use needinfo?) 2011-11-21 10:29:43 PST
(In reply to Michael Coates [:mcoates] from comment #5)
> I'm not sure I'm correctly understanding the comments.  Is this a valid
> issue? If I open the attachment when I'm authenticated will it cause me to
> file an arbitrary bugzilla bug with my account?

Yes, it's a valid issue; yes, that will cause you to file a bug.
Comment 7 Michael Coates [:mcoates] (acct no longer active) 2011-11-21 11:49:13 PST
(In reply to Reed Loden [:reed] (very busy) from comment #6)
> (In reply to Michael Coates [:mcoates] from comment #5)
> > I'm not sure I'm correctly understanding the comments.  Is this a valid
> > issue? If I open the attachment when I'm authenticated will it cause me to
> > file an arbitrary bugzilla bug with my account?
> 
> Yes, it's a valid issue; yes, that will cause you to file a bug.

Then this sounds like a valid security issue that should be addressed. If an attacker can use a CSRF issue to force a power user to file a bug of the attacker's choosing this could be used to cause a fair amount of damage.

Frédéric, Can you explain your thoughts that this is not a security issue?
Comment 8 Mario Gomes 2011-11-21 12:21:34 PST
*** Bug 703983 has been marked as a duplicate of this bug. ***
Comment 9 Mario Gomes 2011-11-21 12:24:35 PST
Created attachment 575938 [details]
Proof of concept File to reproduce the vulnerability(Using http://landfill.bugzilla.org)

Yes, I think that this vulnerability is a risk "medium". Due to enable the User to upload any file.
Look at this example attack:
1. A victim of confidence of the application programmer, reports a security bug with a POC.
2. The victim opens a specially crafted page by an attacker, which contains a code to upload an EXE file.
3. The comment with the malicious EXE file is downloaded and seen by the programmer
4. The programmer, trusting in victim opens the EXE file, thus possibly 
compromising your system.

Reproduce:
1. Create a bug in Bugzilla(https://landfill.bugzilla.org/bugzilla-tip/enter_bug.cgi?product=FoodReplicator)
2. After you create you bug, open the POC attached.
3. Time the ID of you bug created and select the file you want upload.
4. After click in "Submit".
Comment 10 Mario Gomes 2011-11-21 12:27:00 PST
Opps...

Reproduce:
1. Create a bug in Bugzilla(https://landfill.bugzilla.org/bugzilla-tip/enter_bug.cgi?product=FoodReplicator)
2. After you create you bug, open the POC attached.
3. Type the ID of you bug created and select the file you want upload.
4. After click in "Submit".
Comment 11 Frédéric Buclin 2011-11-21 12:37:25 PST
(In reply to Michael Coates [:mcoates] from comment #7)
> Frédéric, Can you explain your thoughts that this is not a security issue?

I explained this in comment 1.
Comment 12 Mario Gomes 2011-11-21 12:43:28 PST
Please, ignore the Comment 9 and 10. I have made a confusion, with other issue. ;)
Comment 13 Max Kanat-Alexander 2011-11-21 12:55:27 PST
Comment on attachment 575741 [details] [diff] [review]
patch, v1

Review of attachment 575741 [details] [diff] [review]:
-----------------------------------------------------------------

::: post_bug.cgi
@@ +62,4 @@
>  
>  # Detect if the user already used the same form to submit a bug
>  my $token = trim($cgi->param('token'));
> +check_token_data($token, 'create_bug', 'index.cgi');

This will still let people click through to file the bug, right? I think that's probably better anyway, for most use cases.

@@ +150,2 @@
>  my $id = $bug->bug_id;
> +delete_token($token);

Hmm, I'm concerned that people could try to do a race condition where they use the same token twice. But I suppose if we moved check_token_data, then people would get their validation errors before the token error, which would be annoying, wouldn't it?

At the very least, let's delete the token before we write to the database.

::: process_bug.cgi
@@ +376,5 @@
>      $bug->send_changes($changes, $vars);
>  }
>  
> +# Delete the session token used for the mass-change.
> +delete_token($token) unless $cgi->param('id');

Why is this change here? Were we not deleting this token? If so, that seems probably like a bug to backport.
Comment 14 Frédéric Buclin 2011-11-21 12:55:45 PST
As discussed with mkanat, we won't fix it on stable branches as some installations and 3rd party applications rely on this feature.
Comment 15 Frédéric Buclin 2011-11-21 13:05:02 PST
(In reply to Max Kanat-Alexander from comment #13)
> This will still let people click through to file the bug, right?

Yes. The user will have the choice between confirming the creation of the bug and canceling the form submission.


> Hmm, I'm concerned that people could try to do a race condition where they
> use the same token twice. But I suppose if we moved check_token_data, then
> people would get their validation errors before the token error, which would
> be annoying, wouldn't it?

Yes, it wouldn't make sense. I'm not too worried about the race condition because once the bug object is created, the token deleted.


> At the very least, let's delete the token before we write to the database.

I can hardly do that, because delete_token() is called right after Bugzilla::Bug->create(). If there is something wrong with the bug creation and the user has to go back to fill missing data, I don't want the token to be already gone as the 2nd form submission would trigger the "Suspicious Action" warning. Note that this race condition, which would be hard to trigger, already exists with the current code.


> Why is this change here? Were we not deleting this token? If so, that seems
> probably like a bug to backport.

Right, we forgot to delete this token during mass-change. I can file a separate bug for it, if you prefer. Just let me know.
Comment 16 Michael Coates [:mcoates] (acct no longer active) 2011-11-21 14:08:57 PST
(In reply to Frédéric Buclin from comment #11)
> (In reply to Michael Coates [:mcoates] from comment #7)
> > Frédéric, Can you explain your thoughts that this is not a security issue?
> 
> I explained this in comment 1.

I guess I asked for further clarification because after reading comment 1 originally I was still confused why you thought this wasn't a security issue. A CSRF vulnerability is definitely a security concern. In terms of risk this is pretty high in my book since it could allow an attacker to force a bugzilla user to submit a bug with the victim's account.  When targeting the correct individual this could lead to some pretty significant actions taking place. (E.g. force an admin to submit a bug asking for a firewall rule change or asking to add someone to a particular security group).

It looks like discussion is continuing on how to fix this issue. If that's the case then there's no need to side track on this discussion.
Comment 17 Frédéric Buclin 2011-11-22 13:06:55 PST
Committing to: bzr+ssh://lpsolit%40gmail.com@bzr.mozilla.org/bugzilla/trunk/
modified enter_bug.cgi
modified post_bug.cgi
modified process_bug.cgi
removed template/en/default/bug/create/confirm-create-dupe.html.tmpl
Committed revision 8011.


Committing to: bzr+ssh://lpsolit%40gmail.com@bzr.mozilla.org/bugzilla/4.2/
modified enter_bug.cgi
modified post_bug.cgi
modified process_bug.cgi
removed template/en/default/bug/create/confirm-create-dupe.html.tmpl
Committed revision 7960.
Comment 18 Frédéric Buclin 2011-11-22 13:28:47 PST
For those who would like to use this patch on their 4.0.x installation: the patch applies cleanly on top of Bugzilla 4.0.2.
Comment 19 Max Kanat-Alexander 2011-11-29 02:39:58 PST
And yeah, we should backport the mass-change token deletion to 4.0 in another bug.
Comment 20 Frédéric Buclin 2011-11-29 07:58:44 PST
(In reply to Max Kanat-Alexander from comment #19)
> And yeah, we should backport the mass-change token deletion to 4.0 in
> another bug.

I filed bug 706118.
Comment 21 Frédéric Buclin 2011-12-29 09:03:12 PST
Security Advisory sent and is live on bugzilla.org. Removing the security flag.
Comment 22 Michael Coates [:mcoates] (acct no longer active) 2012-01-09 14:30:05 PST
updating to ws:high per comment 7

Note You need to log in before you can comment on or make changes to this bug.