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)

3.3.1
defect

Tracking

()

RESOLVED FIXED
Bugzilla 3.4

People

(Reporter: LpSolit, Assigned: LpSolit)

References

Details

(Keywords: regression)

Attachments

(1 file)

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+
Alias: CVE-2009-3387
This has been assigned CVE-2009-3387.
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
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.
Attached patch backout, v1Splinter Review
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 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+
Flags: testcase?
Flags: approval?
Flags: approval3.4?
Blocks: 532517
Flags: blocking3.6+
Flags: approval?
Flags: approval3.4?
Flags: approval3.4+
Flags: approval+
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
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.

Attachment

General

Created:
Updated:
Size: