Note: There are a few cases of duplicates in user autocompletion which are being worked on.
Bug 703983 (CVE-2011-3669)

CSRF vulnerability in attachment.cgi allows possible unauthorized attachment creation

RESOLVED FIXED in Bugzilla 4.2

Status

()

Bugzilla
Attachments & Requests
RESOLVED FIXED
6 years ago
3 years ago

People

(Reporter: x, Assigned: reed)

Tracking

(Blocks: 1 bug)

2.10
Bugzilla 4.2
Dependency tree / graph
Bug Flags:
approval +
approval4.2 +
blocking4.2 +
sec-bounty +

Details

(Whiteboard: [infrasec:csrf][ws:moderate])

Attachments

(2 attachments, 2 obsolete attachments)

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
reproduce:
Make a request without the TOKEN value.

Comment 2

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

Comment 3

6 years ago
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Created attachment 575756 [details]
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".
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".
(Assignee)

Comment 6

6 years ago
Created attachment 575774 [details] [diff] [review]
patch - v1 (untested)
Attachment #575774 - Flags: review?(LpSolit)

Comment 7

6 years ago
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.
(Assignee)

Comment 8

6 years ago
Created attachment 575777 [details] [diff] [review]
patch - v2
Assignee: attach-and-request → reed
Attachment #575774 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #575774 - Flags: review?(LpSolit)
Attachment #575777 - Flags: review?(LpSolit)
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 703975

Comment 11

6 years ago
Leave this bug alone. This is not a duplicate.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---

Updated

6 years ago
Status: REOPENED → ASSIGNED
I'm sorry, I made a Confession. The titles are very similar.

Comment 13

6 years ago
As discussed with mkanat, we won't fix it on stable branches as some installations and 3rd party applications rely on these feature.
Flags: blocking4.2+
Target Milestone: --- → Bugzilla 4.2
Version: unspecified → 4.0.2

Comment 14

6 years ago
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.
Attachment #575777 - Flags: review?(LpSolit) → review+

Updated

6 years ago
Flags: approval?
Flags: approval4.2?
(Assignee)

Comment 15

6 years ago
Created attachment 575967 [details] [diff] [review]
patch - v3
Attachment #575777 - Attachment is obsolete: true
Attachment #575967 - Flags: review+

Comment 16

6 years ago
Approved for immediate checkin. Please leave the sec flag for now when marking the bug as FIXED.
Flags: approval?
Flags: approval4.2?
Flags: approval4.2+
Flags: approval+
(Assignee)

Updated

6 years ago
Summary: CSRF Vulnerability in bug attachment page. → CSRF vulnerability in attachment.cgi allows possible unauthorized attachment creation
Whiteboard: [infrasec:csrf][ws:moderate]
(Assignee)

Comment 17

6 years ago
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.
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago6 years ago
Resolution: --- → FIXED
Reed Loden, you can tell me when that will be released the new version of Bugzilla with this patch?

Comment 19

6 years ago
(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.
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

6 years ago
(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).
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.
Frédéric, I do not understand, if they are not security bugs. Why "Group-Security"?

Comment 24

6 years ago
(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.

Updated

6 years ago
Keywords: relnote
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.
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?
(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.
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

6 years ago
Created attachment 584238 [details]
web bounty awarded - see other attachment

Comment 31

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

Updated

6 years ago
Version: 4.0.2 → 2.10

Updated

6 years ago
Keywords: relnote

Comment 32

6 years ago
Security Advisory sent and is live on bugzilla.org. Removing the security flag.
Group: bugzilla-security
Alias: CVE-2011-3669
(Assignee)

Updated

6 years ago
Blocks: 713348
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?
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.
Okay, sorry for the charging.
Mario,

Chofman sent an email around 12/31 to get more info from you. Let us know if you didn't get it.
Yes, I've received the email and the payment.
Yes, I've received the email and the payment.

Updated

5 years ago
Blocks: 835424
Flags: sec-bounty+
You need to log in before you can comment on or make changes to this bug.