415471 - [SECURITY] A user without canconfirm privs can enter bugs in the NEW/ASSIGNED status using XML-RPC

Status: RESOLVED FIXED

(Bugzilla :: Creating/Changing Bugs, defect)

Description

[Frédéric Buclin]

Bug->create() doesn't make sure that the bug status entered by the user is legal based on his privs. If votes to confirm > 0, then a user with no privs cannot choose the initial bug status; this one must be UNCONFIRMED. Either _check_bug_status() or create() itself should enforce this, maybe using something like:

  delete $params->{bug_status} unless $user->in_group('canconfirm', $product)

Comment 1

[Max Kanat-Alexander]

Have you actually tried this? _check_bug_status has code to explicitly prevent that--it always picks the default status if you're not in canconfirm or editbugs.

Comment 2

[Frédéric Buclin]

(In reply to comment #1)
> Have you actually tried this?

Of course I did, else I would have never noticed it. I have a plenty of bugs filed as ASSIGNED from powerless users. Note that the security flag is not needed here as we never mark bugs affecting development only as such.

Comment 3

[Max Kanat-Alexander]

(In reply to comment #2)
> Note that the security flag is not
> needed here as we never mark bugs affecting development only as such.

  We do, and we have, particularly if it affects a released development version.

Comment 4

[Frédéric Buclin]

Fixed as part of bug 384009. Keeping the security flag till 3.1.4/3.2 RC1 is released.

Comment 5

[Frédéric Buclin]

This regression was introduced by bug 402791 in Bugzilla 3.1.3.

Comment 6

[Max Kanat-Alexander]

Security advisory sent, removing bugs from security group.