Not checking ownership of blocks before editing them
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Mahara |
Fix Released
|
High
|
Son Nguyen | ||
1.5 |
Fix Released
|
Undecided
|
Unassigned | ||
1.6 |
Fix Released
|
Undecided
|
Unassigned | ||
1.7 |
Fix Released
|
Undecided
|
Unassigned | ||
mahara (Debian) |
Fix Released
|
Unknown
|
Bug Description
While working on issue https:/
Steps:
1. Create a Mahara site with two users, A and B
2. User A creates a page with a text block that has ID 35
3. User B creates a page with a text block that has ID 105
4. User B edits their text block, ID 105
5. User B doctors the HTTP request so that the block ID in it is "35" instead of "105"
Result: User A's block 35 has all of its contents overwritten by the settings for block 105.
This attack could be done either by serially guessing IDs, or possibly by getting the ID by looking at a page that the user has view access to.
CVE References
Changed in mahara: | |
assignee: | Robert Lyon (robertl-9) → Son Nguyen (ngson2000) |
information type: | Private Security → Public Security |
no longer affects: | mahara/1.8 |
Changed in mahara: | |
status: | Fix Committed → Fix Released |
affects: | debian → mahara (Debian) |
Changed in mahara (Debian): | |
status: | Unknown → Confirmed |
Changed in mahara (Debian): | |
status: | Confirmed → Fix Released |
There are several different places in the code where it might be appropriate to check for Block ownership. BlockInstance- >instance_ config_ store() is one possibility (though it could be overridden by child blocks).
We check View ownership in blocks.php, so it might make sense to check the block ownership there as well.
Or, in View->process_ changes( ), before we set $this-> blockinstance_ currently_ being_configure d, it might make sense to verify at that point that the block ID is a block that actually belongs to this view.