A group member with no access rights to folder can still view it (if smart :D)

Bug #1034180 reported by Hugh Davenport on 2012-08-07
268
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Mahara
High
Son Nguyen
1.5
High
Unassigned
1.6
High
Unassigned
1.7
High
Unassigned
mahara (Debian)
Fix Released
Unknown

Bug Description

If i create a folder in group files area, open a tab as a normal member, and then as group admin remove all rights to that folder for members, then as the member, click on the folder. The contents of the folder is then displayed (with the following warnings)

 [WAR] 0a (artefact/lib.php:864) Undefined index: member
 Call stack (most recent first):
 log_message("Undefined index: member", 8, true, true, "/var/www/mahara-dev/htdocs/artefact/lib.php", 864) at /var/www/mahara-dev/htdocs/lib/errors.php:446
 error(8, "Undefined index: member", "/var/www/mahara-dev/htdocs/artefact/lib.php", 864, array(size 2)) at /var/www/mahara-dev/htdocs/artefact/lib.php:864
 ArtefactType->role_has_permission("member", "edit") at /var/www/mahara-dev/htdocs/auth/user.php:960
 User->can_edit_artefact(object(ArtefactTypeFolder)) at /var/www/mahara-dev/htdocs/artefact/file/form/elements/filebrowser.php:1221
 pieform_element_filebrowser_edit_group_folder("1", "5") at /var/www/mahara-dev/htdocs/artefact/file/form/elements/filebrowser.php:1308
 pieform_element_filebrowser_changefolder(object(Pieform), array(size 11), "5") at /var/www/mahara-dev/htdocs/artefact/file/form/elements/filebrowser.php:696
 pieform_element_filebrowser_doupdate(object(Pieform), array(size 11)) at /var/www/mahara-dev/htdocs/artefact/file/form/elements/filebrowser.php:362
 pieform_element_filebrowser_get_value(object(Pieform), array(size 11)) at /var/www/mahara-dev/htdocs/lib/pieforms/pieform.php:802
 Pieform->get_value(array(size 11)) at /var/www/mahara-dev/htdocs/lib/pieforms/pieform.php:1253
 Pieform->get_submitted_values() at /var/www/mahara-dev/htdocs/lib/pieforms/pieform.php:490
 Pieform->__construct(array(size 12)) at /var/www/mahara-dev/htdocs/lib/pieforms/pieform.php:161
 Pieform::process(array(size 12)) at /var/www/mahara-dev/htdocs/lib/pieforms/pieform.php:71
 pieform(array(size 12)) at /var/www/mahara-dev/htdocs/artefact/file/groupfiles.php:49
 [WAR] 0a (artefact/lib.php:864) Trying to get property of non-object
 Call stack (most recent first):
 log_message("Trying to get property of non-object", 8, true, true, "/var/www/mahara-dev/htdocs/artefact/lib.php", 864) at /var/www/mahara-dev/htdocs/lib/errors.php:446
 error(8, "Trying to get property of non-object", "/var/www/mahara-dev/htdocs/artefact/lib.php", 864, array(size 2)) at /var/www/mahara-dev/htdocs/artefact/lib.php:864
 ArtefactType->role_has_permission("member", "edit") at /var/www/mahara-dev/htdocs/auth/user.php:960
 User->can_edit_artefact(object(ArtefactTypeFolder)) at /var/www/mahara-dev/htdocs/artefact/file/form/elements/filebrowser.php:1221
 pieform_element_filebrowser_edit_group_folder("1", "5") at /var/www/mahara-dev/htdocs/artefact/file/form/elements/filebrowser.php:1308
 pieform_element_filebrowser_changefolder(object(Pieform), array(size 11), "5") at /var/www/mahara-dev/htdocs/artefact/file/form/elements/filebrowser.php:696
 pieform_element_filebrowser_doupdate(object(Pieform), array(size 11)) at /var/www/mahara-dev/htdocs/artefact/file/form/elements/filebrowser.php:362
 pieform_element_filebrowser_get_value(object(Pieform), array(size 11)) at /var/www/mahara-dev/htdocs/lib/pieforms/pieform.php:802
 Pieform->get_value(array(size 11)) at /var/www/mahara-dev/htdocs/lib/pieforms/pieform.php:1253
 Pieform->get_submitted_values() at /var/www/mahara-dev/htdocs/lib/pieforms/pieform.php:490
 Pieform->__construct(array(size 12)) at /var/www/mahara-dev/htdocs/lib/pieforms/pieform.php:161
 Pieform::process(array(size 12)) at /var/www/mahara-dev/htdocs/lib/pieforms/pieform.php:71
 pieform(array(size 12)) at /var/www/mahara-dev/htdocs/artefact/file/groupfiles.php:49

On a refresh, the home folder is shown, and the folder is not displayed, so can't click on it again.

Although, the member can still access the folder directly, by going to the url /artefact/file/groupfiles.php?group=1&folder=5 (or whatever id's), with the following warnings

 [WAR] 81 (artefact/lib.php:864) Undefined index: member
 Call stack (most recent first):
 log_message("Undefined index: member", 8, true, true, "/var/www/mahara-dev/htdocs/artefact/lib.php", 864) at /var/www/mahara-dev/htdocs/lib/errors.php:446
 error(8, "Undefined index: member", "/var/www/mahara-dev/htdocs/artefact/lib.php", 864, array(size 2)) at /var/www/mahara-dev/htdocs/artefact/lib.php:864
 ArtefactType->role_has_permission("member", "edit") at /var/www/mahara-dev/htdocs/auth/user.php:960
 User->can_edit_artefact(object(ArtefactTypeFolder)) at /var/www/mahara-dev/htdocs/artefact/file/form/elements/filebrowser.php:1221
 pieform_element_filebrowser_edit_group_folder("1", 5) at /var/www/mahara-dev/htdocs/artefact/file/form/elements/filebrowser.php:126
 pieform_element_filebrowser(object(Pieform), array(size 13)) at /var/www/mahara-dev/htdocs/lib/pieforms/pieform.php:1378
 Pieform->build_element_html(array(size 13)) at /var/www/mahara-dev/htdocs/lib/pieforms/pieform.php:659
 Pieform->build() at /var/www/mahara-dev/htdocs/lib/pieforms/pieform.php:162
 Pieform::process(array(size 12)) at /var/www/mahara-dev/htdocs/lib/pieforms/pieform.php:71
 pieform(array(size 12)) at /var/www/mahara-dev/htdocs/artefact/file/groupfiles.php:49
 [WAR] 81 (artefact/lib.php:864) Trying to get property of non-object
 Call stack (most recent first):
 log_message("Trying to get property of non-object", 8, true, true, "/var/www/mahara-dev/htdocs/artefact/lib.php", 864) at /var/www/mahara-dev/htdocs/lib/errors.php:446
 error(8, "Trying to get property of non-object", "/var/www/mahara-dev/htdocs/artefact/lib.php", 864, array(size 2)) at /var/www/mahara-dev/htdocs/artefact/lib.php:864
 ArtefactType->role_has_permission("member", "edit") at /var/www/mahara-dev/htdocs/auth/user.php:960
 User->can_edit_artefact(object(ArtefactTypeFolder)) at /var/www/mahara-dev/htdocs/artefact/file/form/elements/filebrowser.php:1221
 pieform_element_filebrowser_edit_group_folder("1", 5) at /var/www/mahara-dev/htdocs/artefact/file/form/elements/filebrowser.php:126
 pieform_element_filebrowser(object(Pieform), array(size 13)) at /var/www/mahara-dev/htdocs/lib/pieforms/pieform.php:1378
 Pieform->build_element_html(array(size 13)) at /var/www/mahara-dev/htdocs/lib/pieforms/pieform.php:659
 Pieform->build() at /var/www/mahara-dev/htdocs/lib/pieforms/pieform.php:162
 Pieform::process(array(size 12)) at /var/www/mahara-dev/htdocs/lib/pieforms/pieform.php:71
 pieform(array(size 12)) at /var/www/mahara-dev/htdocs/artefact/file/groupfiles.php:49

The second way of accessing also gives a box saying "You do not have permission to add content to this folder", while the first does not, and infact shows the upload file and create folder boxes (though you can't add files)

Both of these ways allow the user to access the files within the folders, or by the url /artefact/file/download.php?file=14

This bug will have to probably change the way permissions work, and backtrack through all the parent folders making sure the user has access

CVE References

Hugh Davenport (hugh-davenport) wrote :

I should note that when using the 1st method to access the folder, and trying to upload files or make new folders, the same error message is shown, so fixing that may lead to being able to upload files/folders

Changed in mahara:
milestone: none → 1.6.0
Changed in mahara:
assignee: nobody → Hugh Davenport (hugh-catalyst)
Hugh Davenport (hugh-davenport) wrote :

    Fix permissions of group area (Bug #1034180)

    A user should not be able to view/publish an artefact if
    - they don't have view/publish permission of that artefact
    - they don't have view permission of all parents of that artefact

    A user should not be able to edit an artefact if
    - they don't have edit permission of that artefact
    - they don't have edit permission of the immediate parent of that artefact
    - they don't have view permission of any parents below the immediate

    This is similar to the UNIX permissions, you shouldn't be able to view
    a directory unless all directories below have read (r) and executeable (x)
    bits set. The same for editing, you need write (w) permissions of the
    immediate parent, and rx for all parents.

    In Mahara, there are no executeable bits, but it can be assumed
    that view is basically the same as rw for container artefacts, and the same
    as r for non container artefacts.

Hugh Davenport (hugh-davenport) wrote :

version for 1.4

Hugh Davenport (hugh-davenport) wrote :

1.2 also needs to be able to run on whatever version of php lucid is stuck on

Hugh Davenport (hugh-davenport) wrote :

actual version for 1.2 xD

Changed in mahara:
status: Confirmed → In Progress
Changed in mahara:
milestone: 1.6.0 → 1.7.0
Aaron Wells (u-aaronw) on 2013-04-19
Changed in mahara:
importance: Medium → High
importance: High → Critical
milestone: 1.7.0 → 1.8.0
Aaron Wells (u-aaronw) wrote :

Whoops, accidentally pushed it as a normal patch instead of a security patch. :( Oh well.

https://reviews.mahara.org/2417

Aaron Wells (u-aaronw) wrote :

One side note about this, we'll probably need to adjust elasticsearch to take this new inheritable permission system into account as well... That may pose a problem. In consulting with Matt C, he pointed out that the main thing you want to make sure of in your permissions system is that the whole thing can be expressed as a single SQL statement. Currently ours can, but if we start having hierarchical permissions (like the permissions descending into folders) it'll be easy to create a system where it can't all be expressed in a standard SQL statement. One way to avoid that problem, is to make sure to add a "path" column to items that are subject to hierarchical permissions -- that makes it possible to look for parents/ancestors with standard SQL "like" clauses.

Aaron Wells (u-aaronw) wrote :

The patch has been merged.

information type: Private Security → Public Security
Changed in mahara:
status: In Progress → Fix Committed
importance: Critical → High
Aaron Wells (u-aaronw) on 2013-09-30
Changed in mahara:
milestone: 1.8rc1 → 1.8.0
Aaron Wells (u-aaronw) on 2013-10-01
Changed in mahara:
assignee: Hugh Davenport (hugh-davenport) → Son Nguyen (ngson2000)

Reviewed: https://reviews.mahara.org/2555
Committed: http://gitorious.org/mahara/mahara/commit/f5cebdef3477c346d98959090937a8d49361fa84
Submitter: Son Nguyen (<email address hidden>)
Branch: 1.6_STABLE

commit f5cebdef3477c346d98959090937a8d49361fa84
Author: Hugh Davenport <email address hidden>
Date: Wed Aug 15 12:07:58 2012 +1200

Fix permissions of group area (Bug #1034180)

A user should not be able to view/publish an artefact if
- they don't have view/publish permission of that artefact
- they don't have view permission of all parents of that artefact

A user should not be able to edit an artefact if
- they don't have edit permission of that artefact
- they don't have edit permission of the immediate parent of that artefact
- they don't have view permission of any parents below the immediate

This is similar to the UNIX permissions, you shouldn't be able to view
a directory unless all directories below have read (r) and executeable (x)
bits set. The same for editing, you need write (w) permissions of the
immediate parent, and rx for all parents.

In Mahara, there are no executeable bits, but it can be assumed
that view is basically the same as rw for container artefacts, and the same
as r for non container artefacts.

Change-Id: I4f84aca05dd08d02b05fbe084e4724f78c8681a0
Signed-off-by: Hugh Davenport <email address hidden>

Mahara Bot (dev-mahara) wrote :

Reviewed: https://reviews.mahara.org/2556
Committed: http://gitorious.org/mahara/mahara/commit/79a810210bfdf89a466876fdf8ac54354f73b73b
Submitter: Son Nguyen (<email address hidden>)
Branch: 1.7_STABLE

commit 79a810210bfdf89a466876fdf8ac54354f73b73b
Author: Hugh Davenport <email address hidden>
Date: Wed Aug 15 12:07:58 2012 +1200

Fix permissions of group area (Bug #1034180)

A user should not be able to view/publish an artefact if
- they don't have view/publish permission of that artefact
- they don't have view permission of all parents of that artefact

A user should not be able to edit an artefact if
- they don't have edit permission of that artefact
- they don't have edit permission of the immediate parent of that artefact
- they don't have view permission of any parents below the immediate

This is similar to the UNIX permissions, you shouldn't be able to view
a directory unless all directories below have read (r) and executeable (x)
bits set. The same for editing, you need write (w) permissions of the
immediate parent, and rx for all parents.

In Mahara, there are no executeable bits, but it can be assumed
that view is basically the same as rw for container artefacts, and the same
as r for non container artefacts.

Change-Id: I4f84aca05dd08d02b05fbe084e4724f78c8681a0
Signed-off-by: Hugh Davenport <email address hidden>

Mahara Bot (dev-mahara) wrote :

Reviewed: https://reviews.mahara.org/2554
Committed: http://gitorious.org/mahara/mahara/commit/0b4952e063f50c001e4c2dfc5749f55258bff952
Submitter: Son Nguyen (<email address hidden>)
Branch: 1.5_STABLE

commit 0b4952e063f50c001e4c2dfc5749f55258bff952
Author: Hugh Davenport <email address hidden>
Date: Wed Aug 15 12:07:58 2012 +1200

Fix permissions of group area (Bug #1034180)

A user should not be able to view/publish an artefact if
- they don't have view/publish permission of that artefact
- they don't have view permission of all parents of that artefact

A user should not be able to edit an artefact if
- they don't have edit permission of that artefact
- they don't have edit permission of the immediate parent of that artefact
- they don't have view permission of any parents below the immediate

This is similar to the UNIX permissions, you shouldn't be able to view
a directory unless all directories below have read (r) and executeable (x)
bits set. The same for editing, you need write (w) permissions of the
immediate parent, and rx for all parents.

In Mahara, there are no executeable bits, but it can be assumed
that view is basically the same as rw for container artefacts, and the same
as r for non container artefacts.

Change-Id: I4f84aca05dd08d02b05fbe084e4724f78c8681a0
Signed-off-by: Hugh Davenport <email address hidden>

Aaron Wells (u-aaronw) on 2013-10-24
Changed in mahara:
status: Fix Committed → Fix Released
Changed in mahara (Debian):
status: Unknown → Confirmed
Changed in mahara (Debian):
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public Security information  Edit
Everyone can see this security related information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.