759174 - CSRF is possible to get source of attachments.

Status: RESOLVED INVALID

(Bugzilla :: Attachments & Requests, defect)

Description

[Mario Gomes]

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

Steps to reproduce:

Hello,

There is no security token while openning attachments. This could allow malicious attachments get the source of critical bugs while a powerfully person visit a malicious page.

A example of attack can be create a malicious attachment on bugzilla.mozilla.org and make some one of Mozilla team to visit this  and get the source of a attachment.

Reproduce(Used on landfill):
1. Log on http://attach.landfill.bugzilla.org/bugzilla-tip/.
2. Go to http://attach.landfill.bugzilla.org/bugzilla-tip/attachment.cgi?id=2620.
3. See the source of attachment 2618 [details](our critical bug poc).

This attack can be exploited by a hidden frame to malicious attachment, as attachment as not protected against clickjacking. So, from www.evil.com is possible exploit this flaw.

Cheers,
Mario.

Comment 1

[Reed Loden [:reed]]

Actually, there are CSRF tokens, but they are only used for bugs in a group or attachments marked private. This was a trade-off done to protect sensitive attachments while not breaking other attachments that require iframe'ing other attachments.

Comment 2

[Reed Loden [:reed]]

Asking for thoughts from others, but I think we've gone over this before.

Comment 3

[Frédéric Buclin]

There is no security issue here, and as reed said in comment 1, it's intentional to let attachments interact together when belonging to the same bug. Moreover, once an attachment is marked as private, your PoC no longer works to get its content as a token is required to access it.

Comment 4

[Dave Miller [:justdave]]

There's a bit of a miscommunication here about what the tokens do...  The tokens everyone is speaking of above are used for authentication when grabbing attachments which are private or on secured bugs in order to prevent your cookies from being shared with the attachments.

We don't have any CSRF protection on attachment viewing at all.  They don't need it.  CSRF protection is intended to prevent unwanted alterations to data, not to prevent the data from being read.  Simple authentication controls and basic domain scoping rules are the protection used for attachment viewing.

Note that the fact you can see the attachment in your IFRAME doesn't necessarily mean anything. On a server set up like b.m.o, each bug has its own domain name for attachments, so attachments loading another attachment in an iframe will only work for attachments on the same bug with it (as far as javascript in the first one being able to actually access the content of the iframe).  On landfill, where you're testing, there's only a single attachment domain rather than one for each bug, so you would indeed have that problem there. That would be a site-specific setup issue, since Bugzilla does allow for the granularity if you can appropriately set up your DNS to handle it.

Comment 5

[Mario Gomes]

Great explanation thanks! :)

(In reply to Dave Miller [:justdave] from comment #4)
> There's a bit of a miscommunication here about what the tokens do...  The
> tokens everyone is speaking of above are used for authentication when
> grabbing attachments which are private or on secured bugs in order to
> prevent your cookies from being shared with the attachments.