297749 - Security Advisory for 2.20rc1 and 2.18.2

Status: RESOLVED FIXED

(Bugzilla :: Bugzilla-General, defect)

Description

[Max Kanat-Alexander]

This bug is secure because it will need to have the Security Advisory posted to
it. Once the Advisory is written, it needs to be reviewed by [e-mail].

The dependencies are the sec bugs that I expect will be fixed by the time of our
release, and thus will need an advisory. :-)

Comment 1

[Frédéric Buclin]

292544 is awaiting approval. 293159 is awaiting review from myk for the 2.18
backport (the patch for the trunk is already reviewed). So if myk could review
it this week, this would be great! ;)

Comment 2

[Myk Melez [:myk] [@mykmelez]]

I just reviewed the backport of the fix for bug 293159.

Comment 3

[Max Kanat-Alexander]

Attachment: DRAFT Security Advisory

LpSolit, both sec bugs were yours, so I'm r?'ing you.

Comment 4

[Frédéric Buclin]

Comment on attachment 188157 [details]
DRAFT Security Advisory

> + Any user can change a flag on any bug, provided the flag is already
>   set to "+" or "-". This also allows the attacker to expose the
>   summary of any bug with a flag set on it.

I did some additional tests today and the conclusions are even worse:

1) the flag is usable independently of its status: "?", "+" or "-".
2) the flag is usable even if it has been cancelled (flags.is_active = 0).
3) attachment flags also give the name of the attachment.
4) no entry in the bugs_activity table is added, meaning that no email is sent
to other users (neither the assignee nor the QA contact) and consequently
nothing is visible from the show_activity.cgi page.

In other words, you have no way to know if you have been attacked *except* by a
direct look at the flags table (i.e. without using the Bugzilla UI):

A) the setter_id field contains the user ID of the last user who changed the
flag. This is the only way to know who attacked your DB.

B) the modification_date field is set to 0000-00-00 00:00:00, meaning that you
cannot know when the attack occured. This may only indicate that this flag has
been used by the attacker.


The single good news is:

4) the flag cannot be used by the attacker if this user is not allowed to
change this flag type under normal conditions, due to restrictions based on
flagtypes.grant_group_id and flagtypes.request_group_id.


>Description: Any bugzilla user can expose the summary of any bug with a
>             flag set to "+" or "-" on it. Also, any Bugzilla user can
>             change a flag on a bug that they should not normally be able
>             to access.

Wrong (or incomplete) per my previous comment.


>             By manually modifying a link to process_bug.cgi, it is possible
>             to change a flag on a bug that you do not have access to,
>             because Bugzilla does not validate that the flag you are 
>             attempting to change is associated with the bug that you 
>             are attempting to change. The flag must be already set to "+"
>             or "-" for this to work.

Except this last sentence about +/-, it's ok.


>             The attacker can set this flag to "?", and then cancel it.
>             As he was the requester, he will get an email about his
>             flag change. The email will include the title (summary) of 
>             the bug.

I also discovered that cancelling the request is not the only way to get the
bug summary. The attacker simply needs to set himself as the requestee. This
way, he will get an email asking him to set this flag. He will receive a second
email (again with the bug summary in it) when cancelling this request, now
because he is the requester.


The description of the second issue is fine.

Comment 5

[Max Kanat-Alexander]

Attachment: v2

OK, fixed the comments.

Comment 6

[Frédéric Buclin]

Comment on attachment 188629 [details]
v2

looks good. r=LpSolit

Comment 7

[Max Kanat-Alexander]

OK, secadv sent to all three places. Thanks for the reviews, LpSolit! :-)