Last Comment Bug 417048 - (CVE-2010-2756) [SECURITY] Boolean charts let me query for users being in any given group
(CVE-2010-2756)
: [SECURITY] Boolean charts let me query for users being in any given group
Status: RESOLVED FIXED
:
Product: Bugzilla
Classification: Server Software
Component: Query/Bug List (show other bugs)
: 2.19.1
: All All
: -- normal (vote)
: Bugzilla 3.2
Assigned To: Frédéric Buclin
: default-qa
Mentors:
Depends on: 579797
Blocks: 580214
  Show dependency treegraph
 
Reported: 2008-02-12 11:46 PST by Frédéric Buclin
Modified: 2010-08-05 21:39 PDT (History)
4 users (show)
LpSolit: approval+
LpSolit: approval4.0+
LpSolit: blocking4.0+
LpSolit: approval3.6+
mkanat: blocking3.6.2+
LpSolit: approval3.4+
LpSolit: blocking3.4.8+
LpSolit: approval3.2+
mkanat: blocking3.2.8+
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
patch for 3.4 - 4.0, v1 (1.33 KB, patch)
2010-07-06 07:15 PDT, Frédéric Buclin
mkanat: review+
Details | Diff | Review
patch for 3.2, v1 (1.32 KB, patch)
2010-07-06 09:29 PDT, Frédéric Buclin
mkanat: review+
Details | Diff | Review
patch for 4.2, v1 (1.31 KB, patch)
2010-07-20 03:24 PDT, Frédéric Buclin
mkanat: review+
Details | Diff | Review

Description Frédéric Buclin 2008-02-12 11:46:37 PST
"ReportedBy" "is equals to" "%group.admin%" returns all bugs where the reporter is in the admin group, despite I'm not in the admin group and despite I cannot access editusers.cgi (as I cannot bless anybody). AFAIK, such data should be restricted to power users who can access editusers.cgi. Moreover, query.cgi throws an error if I type a group name which doesn't exist, so I can use this trick to guess existing groups.

IMO, query.cgi should only let you enter group names you belong to, nothing more. Talking about this with dveditz and justdave on IRC, they both think it's not a problem on b.m.o, because they don't matter if people know who is in which group, but it may matter for some other installations, which is why I restricting this bug to the security group.

The %group.foo% group substitution feature has been implemented in Bugzilla 2.20 in bug 244239, so this problem exists for a long time.
Comment 1 Max Kanat-Alexander 2008-02-12 12:19:32 PST
Yes, I agree this is a security issue, for some installations, though not extremely serious.
Comment 2 Frédéric Buclin 2008-12-07 06:25:37 PST
Bugzilla 2.20 is no longer supported. Retargetting to 2.22.
Comment 3 Frédéric Buclin 2009-07-28 13:08:17 PDT
Bugzilla 2.x is no longer supported. Retargetting to 3.0.
Comment 4 Frédéric Buclin 2010-04-13 00:05:44 PDT
Bugzilla 3.0 is EOL. We will retarget this bug when it's fixed.
Comment 5 Frédéric Buclin 2010-07-06 07:15:13 PDT
Created attachment 456161 [details] [diff] [review]
patch for 3.4 - 4.0, v1

Restrict the usage of %group.foo% to groups you belong to. Group visibility is already handled by ValidateGroupName().
Comment 6 Max Kanat-Alexander 2010-07-06 09:08:35 PDT
  Once we branch, Search.pm is going to change pretty rapidly. I already know that the area around this patch will change with a patch that I already have pending checkin. But the patch should be un-bitrottable with little change.
Comment 7 Frédéric Buclin 2010-07-06 09:29:42 PDT
Created attachment 456168 [details] [diff] [review]
patch for 3.2, v1

Same patch as for 3.4 - 4.0, but fixed a tiny bitrot.
Comment 8 Max Kanat-Alexander 2010-07-17 13:51:58 PDT
It should be safe to re-write the patch for trunk now. The code moved into a different location than it is in 4.0, so the 4.0 patch won't apply.
Comment 9 Frédéric Buclin 2010-07-18 16:45:56 PDT
(In reply to comment #8)
> It should be safe to re-write the patch for trunk now.

Bug 579797 must be fixed first, as Search.pm now leaks too much information.
Comment 10 Max Kanat-Alexander 2010-07-19 01:48:11 PDT
(In reply to comment #9)
> Bug 579797 must be fixed first, as Search.pm now leaks too much information.

  No, it does not, see my comment there. We decided that group names are no longer confidential in the guessing sense. That is, if you guess, we'll tell you explicitly whether or not they don't exist. If you want to have a technical discussion about this, we should do it on the developers list.
Comment 11 Frédéric Buclin 2010-07-20 03:24:24 PDT
Created attachment 458607 [details] [diff] [review]
patch for 4.2, v1
Comment 12 Max Kanat-Alexander 2010-07-20 03:27:22 PDT
Comment on attachment 458607 [details] [diff] [review]
patch for 4.2, v1

Looks good.
Comment 13 Frédéric Buclin 2010-08-04 14:36:54 PDT
Committing to: bzr+ssh://lpsolit%40gmail.com@bzr.mozilla.org/bugzilla/trunk/
modified Bugzilla/Search.pm
Committed revision 7428.

Committing to: bzr+ssh://lpsolit%40gmail.com@bzr.mozilla.org/bugzilla/4.0/
modified Bugzilla/Search.pm
Committed revision 7369.

Committing to: bzr+ssh://lpsolit%40gmail.com@bzr.mozilla.org/bugzilla/3.6/
modified Bugzilla/Search.pm
Committed revision 7157.

Committing to: bzr+ssh://lpsolit%40gmail.com@bzr.mozilla.org/bugzilla/3.4/
modified Bugzilla/Search.pm
Committed revision 6771.

Committing to: bzr+ssh://lpsolit%40gmail.com@bzr.mozilla.org/bugzilla/3.2/
modified Bugzilla/Search.pm
Committed revision 6392.
Comment 14 Max Kanat-Alexander 2010-08-05 21:39:44 PDT
Security advisory sent, unlocking bug.

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