Closed
Bug 532493
(CVE-2009-3387)
Opened 15 years ago
Closed 14 years ago
[SECURITY] Restricting a bug to a group while moving it to another product has no effect if the group is not used by both products
Categories
(Bugzilla :: Creating/Changing Bugs, defect, P1)
Tracking
()
RESOLVED
FIXED
Bugzilla 3.4
People
(Reporter: LpSolit, Assigned: LpSolit)
References
Details
(Keywords: regression)
Attachments
(1 file)
4.16 KB,
patch
|
mkanat
:
review+
|
Details | Diff | Splinter Review |
When moving a bug to a new product which doesn't use all the same groups as the original product, trying to restrict the bug to a group which doesn't exist in the original product has no effect; the bug is left public. This happened to me right now on bmo when moving a security bug from mozilla.org to Bugzilla. If the group exists in both products, it's restricted correctly. Bugzilla 3.2.5 is not affected, so that's a regression in 3.4.x and HEAD only.
Flags: blocking3.4.5+
Updated•15 years ago
|
Alias: CVE-2009-3387
Comment 1•15 years ago
|
||
This has been assigned CVE-2009-3387.
Assignee | ||
Comment 2•15 years ago
|
||
I found what's wrong. In process_bug.cgi line 249, you have: foreach my $group (@{$bug->product_obj->groups_valid}) But at this point, the bug hasn't been moved into the new product yet and so we only loop over groups being valid for the old product, not the new one (despite the UI offered you to choose amongst groups for the new product, as expected), and so all groups not available in the old product are ignored. This means we must update $bug->product_obj *before* looking at group restrictions. This is a regression due to bug 428440, which implemented $bug->set_all(), and so Bugzilla 3.3.1 and above are all affected.
Depends on: 428440
Version: 3.4.4 → 3.3.1
Assignee | ||
Comment 3•15 years ago
|
||
As $bug->set_all is bogus and nothing else besides this specific code uses it, we should backout bug 428440, and reimplement it correctly in 3.8.
Assignee | ||
Comment 4•15 years ago
|
||
Backout of bug 428440. I confirm that this fixes the problem.
Assignee: create-and-change → LpSolit
Status: NEW → ASSIGNED
Attachment #415719 -
Flags: review?(mkanat)
Comment 5•15 years ago
|
||
Comment on attachment 415719 [details] [diff] [review] backout, v1 Yes, a straight back-out of this code is totally fine.
Attachment #415719 -
Flags: review?(mkanat) → review+
Assignee | ||
Updated•15 years ago
|
Flags: testcase?
Flags: approval?
Flags: approval3.4?
Assignee | ||
Updated•15 years ago
|
Flags: blocking3.6+
Assignee | ||
Updated•14 years ago
|
Flags: approval?
Flags: approval3.4?
Flags: approval3.4+
Flags: approval+
Assignee | ||
Comment 7•14 years ago
|
||
tip: Checking in process_bug.cgi; /cvsroot/mozilla/webtools/bugzilla/process_bug.cgi,v <-- process_bug.cgi new revision: 1.428; previous revision: 1.427 done Checking in Bugzilla/Bug.pm; /cvsroot/mozilla/webtools/bugzilla/Bugzilla/Bug.pm,v <-- Bug.pm new revision: 1.308; previous revision: 1.307 done 3.4.4: Checking in process_bug.cgi; /cvsroot/mozilla/webtools/bugzilla/process_bug.cgi,v <-- process_bug.cgi new revision: 1.417.2.2; previous revision: 1.417.2.1 done Checking in Bugzilla/Bug.pm; /cvsroot/mozilla/webtools/bugzilla/Bugzilla/Bug.pm,v <-- Bug.pm new revision: 1.276.2.14; previous revision: 1.276.2.13 done
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Comment 8•14 years ago
|
||
Security advisory sent, removing from security group.
Group: bugzilla-security
You need to log in
before you can comment on or make changes to this bug.
Description
•