703983 - (CVE-2011-3669) CSRF vulnerability in attachment.cgi allows possible unauthorized attachment creation

Status: RESOLVED FIXED

(Bugzilla :: Attachments & Requests, defect)

Description

[Mario Gomes]

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:

Hi,

all tests done in https://landfill.bugzilla.org/bugzilla-tip/show_bug.cgi?id=16552.

A vulnerability exists in the upload page bugzilla when a request is made and the value of "token" is not sent to the Bugzilla server, an error occurs allowing XSRF attacker to induce a victim to upload a file in a bug reported, without him knowing.





Actual results:

Upload the file


Expected results:

The file is upload

Comment 1

[Mario Gomes]

reproduce:
Make a request without the TOKEN value.

Comment 2

[Frédéric Buclin]

I don't understand your description. Could you give exact steps to reproduce?

Comment 3

[Frédéric Buclin]

Ah, I see what you mean. A token is not required to upload an attachment. We require one when editing attachments, though, see bug 476603. This case falls under the same consideration as bug 703975, i.e. an attacker doesn't need you to upload attachments. We protected editing attachments because an attacker could inadvertendly force a power user to remove the private bit of a private attachment. But I guess it's fine to also require a token when uploading a new attachment.

Comment 4

[Mario Gomes]

Attachment: Proof of concept File to reproduce the vulnerability

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 5

[Mario Gomes]

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 6

[Reed Loden [:reed]]

Attachment: patch - v1 (untested)

Comment 7

[Frédéric Buclin]

Comment on attachment 575774 [details] [diff] [review]
patch - v1 (untested)

>=== modified file 'attachment.cgi'
>+    check_token_data($token, 'create_attachment');

You have to pass a 3rd argument to redirect the user to a useful page if he get the "suspicious action" page. 'index.cgi' seems a reasonable choice.


>-  # Assign the bug to the user, if they are allowed to take it
>-  my $owner = "";
>-  if ($cgi->param('takebug') && $user->in_group('editbugs', $bug->product_id)) {
>+    # Assign the bug to the user, if they are allowed to take it
>+    my $owner = "";
>+    if ($cgi->param('takebug') && $user->in_group('editbugs', $bug->product_id)) {

Don't bother fixing the indentation here. There are many places where the indentation is wrong in this file. I only bother fixing it when I touch these lines specifically, to not break the history of the file.


Otherwise looks good, but I haven't tested your patch yet. I will test an updated one.

Comment 8

[Reed Loden [:reed]]

Attachment: patch - v2

Comment 11

[Frédéric Buclin]

Leave this bug alone. This is not a duplicate.

Comment 12

[Mario Gomes]

I'm sorry, I made a Confession. The titles are very similar.

Comment 13

[Frédéric Buclin]

As discussed with mkanat, we won't fix it on stable branches as some installations and 3rd party applications rely on these feature.

Comment 14

[Frédéric Buclin]

Comment on attachment 575777 [details] [diff] [review]
patch - v2

>=== modified file 'attachment.cgi'
>+  # Delete the token used to create this attachment.
>+  delete_token($token);

This line should go right after the call to Bugzilla::Attachment->create(). No need to wait for other attachments to be marked as obsolete and the comment written. This token is used for the attachment creation, after all.

r=LpSolit with an updated patch attached which addresses this comment.

Comment 15

[Reed Loden [:reed]]

Attachment: patch - v3

Comment 16

[Frédéric Buclin]

Approved for immediate checkin. Please leave the sec flag for now when marking the bug as FIXED.

Comment 17

[Reed Loden [:reed]]

Committing to: bzr+ssh://bzr.mozilla.org/bugzilla/trunk/
modified attachment.cgi
deleted template/en/default/attachment/cancel-create-dupe.html.tmpl
Committed revision 8009.

Committing to: bzr+ssh://bzr.mozilla.org/bugzilla/4.2/
modified attachment.cgi
deleted template/en/default/attachment/cancel-create-dupe.html.tmpl
Committed revision 7959.

Comment 18

[Mario Gomes]

Reed Loden, you can tell me when that will be released the new version of Bugzilla with this patch?

Comment 19

[Frédéric Buclin]

(In reply to Mario Gomes from comment #18)
> Reed Loden, you can tell me when that will be released the new version of
> Bugzilla with this patch?

You can track progress in bug 702713. Note that Bugzilla 4.0.3 won't have this fix.

Comment 20

[Mario Gomes]

Well, that's embarrassing to me... ;(
But as the "ws:moderate" and how the Mozilla bugs or "ws:critical" as stated here "In the past we have not paid Formally the bug bounty on web vulnerabilities but we have paid for the bounty extraordinary and critical web application vulnerabilities". Just to confirm, this bug and the bug 703975 not eligible for a bounty. Right?

Comment 21

[Frédéric Buclin]

(In reply to Mario Gomes(http:///net-fuzzer.blogspot.com) from comment #20)
> web application vulnerabilities". Just to confirm, this bug and the bug
> 703975 not eligible for a bounty. Right?

That's not my decision, but they are honestly not security bugs, only security enhancements (which is the reason why we didn't backport them to stable branches).

Comment 22

[Yvan Boily [:ygjb][:yvan]]

Hi Mario,

There is a team that meets periodically to review submitted bugs and determine if they qualify for the bounty program; once that is done they will update the bug report with the decision.

Comment 23

[Mario Gomes]

Frédéric, I do not understand, if they are not security bugs. Why "Group-Security"?

Comment 24

[Frédéric Buclin]

(In reply to Mario Gomes(http://net-fuzzer.blogspot.com) from comment #23)
> Frédéric, I do not understand, if they are not security bugs. Why
> "Group-Security"?

To avoid people playing with your Proof of Concept before we release new versions.

Comment 25

[Mario Gomes]

Okay. Thanks for reponse.  
(In reply to Yvan Boily [:ygjb][:yvan] from comment #22)
> Hi Mario,
> 
> There is a team that meets periodically to review submitted bugs and
> determine if they qualify for the bounty program; once that is done they
> will update the bug report with the decision.

Comment 27

[Mario Gomes]

is amazing, nothing what i do, is eligible for a reward. Why Mozilla creates the Rewards Program if you do not want to pay? And also to put failures CSRF in Critical if the maximum severity is Moderate?

Comment 28

[Michael Coates [:mcoates] (acct no longer active)]

(In reply to Mario Gomes(@NetFuzzer) from comment #27)
> is amazing, nothing what i do, is eligible for a reward. Why Mozilla creates
> the Rewards Program if you do not want to pay? And also to put failures CSRF
> in Critical if the maximum severity is Moderate?

Mario,

I think you may have received incorrect information somewhere.

The combination of issues listed in this bug and bug 703975 have been evaluated and are going to be paid as part of the bug bounty.  Chris Hoffman will be contacting you to arrange payment.

Comment 29

[Mario Gomes]

Great - Thanks! :)

(In reply to Michael Coates [:mcoates] from comment #28)
> (In reply to Mario Gomes(@NetFuzzer) from comment #27)
> > is amazing, nothing what i do, is eligible for a reward. Why Mozilla creates
> > the Rewards Program if you do not want to pay? And also to put failures CSRF
> > in Critical if the maximum severity is Moderate?
> 
> Mario,
> 
> I think you may have received incorrect information somewhere.
> 
> The combination of issues listed in this bug and bug 703975 have been
> evaluated and are going to be paid as part of the bug bounty.  Chris Hoffman
> will be contacting you to arrange payment.

Comment 30

[chris hofmann]

Attachment: web bounty awarded - see other attachment

Comment 31

[chris hofmann]

adding the nomination.  can someone update the award level and I'll contact Mario next week.

Comment 32

[Frédéric Buclin]

Security Advisory sent and is live on bugzilla.org. Removing the security flag.

Comment 33

[Mario Gomes]

Google, Facebook, Pwiki, CCBill secure and
classified all the rewards and pay quickly, do
not understand why Mozilla is so slow.
"Contact in next week" the week has release
a patch for the vulnerability, and no telling
anything about the payment. Why so much
delay Mozilla?

Comment 34

[Michael Coates [:mcoates] (acct no longer active)]

Mario,

Apologies for any delays. I'll check into the status of things.  Many people are not working during this holiday period and sometimes items take a few days longer than normal.

Comment 35

[Mario Gomes]

Okay, sorry for the charging.

Comment 36

[Michael Coates [:mcoates] (acct no longer active)]

Mario,

Chofman sent an email around 12/31 to get more info from you. Let us know if you didn't get it.

Comment 37

[Mario Gomes]

Yes, I've received the email and the payment.

Comment 38

[Mario Gomes]

Yes, I've received the email and the payment.