0010053: Security holes in bug_update.php allow reporters to do changes that should not be allowed

ID	Project	Category	View Status	Date Submitted	Last Update
0010053	mantisbt	security	public	2009-01-15 15:09	2011-10-09 05:37

Reporter	olegos	Assigned To	dhx
Priority	normal	Severity	major	Reproducibility	always
Status	closed	Resolution	duplicate
Product Version	1.2.0a3

Summary	0010053: Security holes in bug_update.php allow reporters to do changes that should not be allowed
Description	See bug 0010038. I should not have been able to cause Resolved->Confirmed transition. The problem is that bug_update.php first does all access checks, then all updates. It's possible to pass the check based on one thing, then change something unrelated (like in this case, the check passed because I'm a reporter and allowed to reopen issue, but I was really asking for a transition to Confirmed, which indeed was performed). I'm pretty sure I can change any field using this method too. This would have been partially fixed by the patch I attached to 0009828. The real fix is to either validate 1 act on 1 validate 2 act on 2 ... Or set a bunch of flags as part of validation to preserve what exactly has been validated (which is what I sort-of started doing in the patch with reopen_flag).
Tags	No tags attached.

olegos 2009-01-16 09:47 reporter ~0020638	By the way, this issue is very serious. It may not seem so -- big deal, I can modify my own issues. But on my system, I allow any reporter to reopen any issue (since they can submit a new issue anyway, why have several issues for the same thing; and I set reopen state to NEW). So this bug allows any reporter to modify any issue.

dhx 2010-06-19 01:13 reporter ~0025919	Sorry for the delayed response. This issue will be resolved very shortly (I'm finishing up a complete rewrite of bug_update.php). Please see 0012097 for more information. Please note that your suggestion to validate 1, act on 1, validate 2, act on 2 is incorrect as it allows for partial commits of data to the database. We need to first validate everything the user has requested to change and then only once everything is valid should be commit the results to the database. More information/discussion in 0012097 if you're interested.