User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:39.0) Gecko/20100101 Firefox/39.0
Build ID: 20150630154324
Steps to reproduce:
Bug type : Indirect object reference
Description : In Bugzilla Website you have a functionality to filter your bug mails called "Bugmail filter". You can create you bugmail filter to filter your bugzilla bugs.
Issue : Delete request of the bugmail filter created by sent a Filter ID which is not validating on server side and you can delete any user's Bugmail filter and even delete all user's bugmail filter.
You can also refer mentioned Link for Video POC :
HTTP request :
POST /userprefs.cgi HTTP/1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:39.0) Gecko/20100101 Firefox/39.0
Accept-Encoding: gzip, deflate
Cookie: Bugzilla_github_token=peKIJc8wW1; Bugzilla_login=534686; Bugzilla_logincookie=qgfeDRMXaNibsREVnuq6LB
Here value of parameter remove is not validating on server side and you can change it to any user's bugmail filter ID and it will be deleted.
Id should be associated with user's account and should be validated at server side or any hash Id should be generated while creating a bugmail Filter.
3dae100..8dd0fac master -> master
the impact of this issue is the target user will receive more bugmail than expected.
Didn't we have another bug similar to this recently? Is it worth checking other "delete" actions to make sure we appropriately validate the ID of the thing to be deleted?
(In reply to Gervase Markham [:gerv] from comment #2)
> Didn't we have another bug similar to this recently? Is it worth checking
> other "delete" actions to make sure we appropriately validate the ID of the
> thing to be deleted?
yes, and i've already performed that audit. i didn't find any other occurrences.
Unlike the Component watching deletion where a user might miss important bug notifications, this one simply results in more mail getting sent. Annoying as hell to clean up but easily noticed and corrected. Not awarding a bounty.
You are completely correct with your use case Here.But if you think of some more attacks in this,it's also a very important feature to exploit.
Ex: If User is getting the important mails according to his search settings and get all the bugs where he should be part of or he's following.Now if Attacker delete his search filtering,he won't be getting any mails which are important and it'll effect him a lot. Now even if he notify this after sometimes and create/update his search filter again,Attacker always has power to delete his search filtering.
If you think in a organization level where you are part of a group email and if you don't get the mails,How effective it will be for current work and image in a organization.
I completely agree with your point when you are comparing it with component watching feature and i agree it's not much critical then component watching feature so you can put it in low security bugs category. My component watching delete bug was sec-moderate level bug . I am not saying it should also be coming in the same category but it should be considered in low category security bugs and should be rewarded according low category bug.
Kindly Make the proper decision considering the security level of the bug.
Best Regards !
(In reply to vijay kumar1 from comment #6)
> Ex: If User is getting the important mails according to his search settings
> and get all the bugs where he should be part of or he's following. Now if
> Attacker delete his search filtering,h e won't be getting any mails which are
> important and it'll effect him a lot.
the bugmail filtering system allows the user to configure bugzilla to *not send* emails that match the filter criteria.
the flow is:
bug updated --> build list of recipients --> execute filtering rules --> deliver unfiltered email
it wasn't possible to use this bug in a way which would result in important email not being sent.