Arbitrary image download

Bug #1211758 reported by Tom on 2013-08-13
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Robert Lyon
mahara (Debian)
Fix Released

Bug Description

I've discovered a few vulnerabilities within Mahara that allow any user to view private images + blog posts of other users. Disclosure: I know nothing about Mahara and have only used it for the last 2-3 hours, please forgive me if I am wrong in my assumptions about the architecture/functionality.

#1: Upload permissions are not properly checked when creating a journal
When creating a journal entry a user can attach any arbitrary object by ID. From what I can tell every object (file, journal, picture etc) are the same object (artifact?), or at least all have a unique ID. This means that if use the file browser to select a file that you can view, then modify the ID (using Chromes developer tools or in-flight using Burp) to an ID of a folder, journal entry or image then that object will be attached to the journal entry.

Here is a screenshot of the issue:
In that image Picture1.png, maxresdefaults.jpg and "tok123tok123's Journal" belong to other users (and give permission errors if you attempt to view them).

#2: Object permissions and types are not correctly checked when embedding content within a page
It is possible to embed private objects belonging to other users within a page. In this screenshot I have created a page and attached it to a collection. None of the objects in those blocks belong to the current user (and hence are un-viewable), and all are private (the journal entry to the right is unpublished).

You can also select an image file to be embedded as a HTML file (under the 'Some HTML' heading) and get the file contents. You can select a folder, but this causes a 500 error.

When editing a block and selecting an upload the page sends a instconf_artefactid_selected[ID] parameter to the server. Simply manipulating the ID in the brackets and the value will let you embed any object.

#3: Export function allows arbitrary file download
Using the technique above you can get a 1024x1024 'thumbnail' of any users arbitrary file. Simply use the export function on a page like the one above where other users images are embedded. Make sure the embedded images max-size is set to 1024 and it will appear within /files/extra.

I know these are not serious issues, but I'm sure there are other permission related issues to be found. I concentrated mainly on the journal and collection features.

CVE References

Tom (orf) on 2013-08-13
description: updated
description: updated
Tom (orf) wrote :

Nobody seemed interested so I made it public. Its not exactly a 0day anyway.

information type: Private Security → Public Security

Hello Tom,

Thank you very much for your report.

I'm sorry that nobody had yet responded to your report. I was only recently added to the security group, but only after you had sent your report. We take security seriously at Mahara and do try to respond to any reports very quickly. Unfortunately, this had slipped our attention.

One of our developers will look into this and get back to you as soon as possible.

As it does concern permissions that could be exploited, I reverted the report back to "Private Security".

Thank you again for your report.


information type: Public Security → Private Security
Changed in mahara:
assignee: nobody → Aaron Wells (u-aaronw)
status: New → Triaged
Aaron Wells (u-aaronw) wrote :

Hi all,

Yeah, sorry about not responding. It appears that our security team wasn't getting subscribed to new security bugs. So, I'm looking into that as well.


Aaron Wells (u-aaronw) on 2013-08-28
Changed in mahara:
importance: Undecided → High
Aaron Wells (u-aaronw) on 2013-09-08
Changed in mahara:
assignee: Aaron Wells (u-aaronw) → nobody
assignee: nobody → Robert Lyon (robertl-9)
Robert Lyon (robertl-9) on 2013-09-09
Changed in mahara:
status: Triaged → Confirmed
Aaron Wells (u-aaronw) wrote :

Hi Robert,

While working on the Page Skins feature, I had an idea relating to this. One way we can help verify that all attached File artefacts are ones that the user is allowed to use, is that we could put it in the Pieform filebrowser element. Normally, the best function to put it in would probably be the pieform_element_{$type}_set_attributes() function, but in the case of filebrowser it hacks the normal control flow for Pieforms and does the upload in pieform_element_filebrowser_get_value(). So we'd have to place it in there somewhere if we were to do this.

If the other artefact selectors are using Pieform elements, we may be able to use something similar for them.


Robert Lyon (robertl-9) wrote :

Hi Aaron,

The problem is the site looks to save bad values without actually calling the pieform_element_filebrowser_get_value()

When I save valid data the function is called but if I do the hack and save bad data the function is not called.

the only consistent joy I can get (so far) is checking the function instance_config_store(Pieform $form, $values)
and am able to check there if the artefactids are valid

Aaron Wells (u-aaronw) wrote :

Robert posted a patch for this:

Aaron Wells (u-aaronw) wrote :

Okay, the patch has been reviewed and approved. The final merge patches:


Aaron Wells (u-aaronw) wrote :

Hi Tom,

I just wanted to say thanks again for this report. Looking through the code to resolve this issue, it appears that the Mahara code base is pretty thorough about checking that the user always has the correct permissions for Pages that they want to manipulate, but it was not as thorough about Artefacts. (As you noted, all content in Mahara is stored as an abstract "artefact").

We've developed a patch which covers all the loopholes we could find, and we'll release that shortly in our next minor release. I'm sure there may be some spots that we've missed, so please do let us know if you find any others.

By the way, do you want to be listed on the Mahara security contributors page?


Aaron Wells (u-aaronw) on 2013-10-03
information type: Private Security → Public Security
Aaron Wells (u-aaronw) wrote :

We had difficulty implementing a fix for issue #3 in this bug's description: the export of pages that already include links to other users' artefacts. So since preventing the linking to other users' artefacts mitigates the risk of that vulnerability somewhat, I've gone ahead and spun that out into a separate bug:

Aaron Wells (u-aaronw) on 2013-10-24
no longer affects: mahara/1.8
Changed in mahara:
status: Fix Committed → Fix Released
Changed in mahara (Debian):
status: Unknown → Confirmed
Tom (orf) wrote :

Heya Aaron,
I would quite like to be listed on the security contributors page, could you link to my blog at ?


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.

Other bug subscribers

Remote bug watches

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