Can cause arbitrary SWF files to execute in the browser

[Aaron Wells]

Subject: Found Critical XSS Vulnerability on Your System

Hello,

I found a really critical XSS (Cross Site Scripting) vulnerability on mahara.org. The vulnerability works as follows:

1) I opened the demo account on Mahara and logged in the admin account by using the link "http://demo.mahara.org/".

2) Then I clicked admin avatar picture to go to user details page.

3) After that I clicked "edit this page" button.

4) Then I dragged "File(s) to Download image to About me section of the page.
5) I created a .swf file that contains ActionScript codes. I also attached that file to this email.

6) I uploaded that XSS.swf file.

7) When I open XSS.swf file on browser, I saw the alert message showing SOLVER (my nickname)

8) Example script: http://demo.mahara.org/artefact/file/download.php?file=247

By using this XSS vulnerability, an attacker can steal Mahara users' cookies, and their accounts. Furthermore, the attacker can redirect users to a harmful website that contains trojan horse, malware or a JavaScript downloader to get full access on the users' computers. This issue can get bigger by using a XSS Worm, and influence even some other Mahara product users.

As a simple solution, the content of the file that is about to be uploaded should be checked against harmful scripts and codes.

[Aaron Wells (u-aaronw)]

Flash files are only able to access the content of the page they're loaded in, if they are hosted at the same domain as the page. For this reason, most sites that host user-uploaded Flash files (including launchpad, and kongregate.com), host them at a different domain than the webpage itself.

Since Mahara is a hosted app, well, it's not really feasible to ask all of the users on shared hosting to set that up. Although we could provide support for it, for larger sites. I suggest one or more of the following courses of action:

1. Add the HTTP header "content-disposition:attachment" to all flash files that are viewed as attachments. (i.e., you put a flash file in a "Files to download" block.) Currently, they're displayed as "content-disposition:inline", which makes them be viewed inside the browser.

2. For that matter, it would probably be better if all "files for download" had "content-disposition:attachment". This will make the browser download them rather than try to display them in the browser, and isn't that what a user expects from "files to download"?

3. Make sure that when we embed SWF files in the internalmedia block, we use "allowscriptaccess=never" and "allownetworking=never" in the embed params (and maybe check for other suitable limitations in http://blogs.adobe.com/stateofsecurity/2007/07/how_to_restrict_swf_content_fr_1.html )

4. Add support for user-uploaded files to be served from a different domain. This would be in the form of something like $cfg->uploadwwwroot, which would default to $cfg->wwwroot if it's not supplied. $cfg->uploadwwwroot should serve exactly the same content as $cfg->wwwroot, but its purpose would be to be used in place of $cfg->wwwroot whenever we want a URL for serving user-supplied files.

[Robert Lyon (robertl-9)]

I agree about having the artefact/file/download.php file have forcedownload on by default (and not overridable) - it would be a matter of checking if that causes problems with things that are using that url but should not be.

I notice there is this page talking about how to get around the 'allowscriptaccess' variable:
https://soroush.secproject.com/blog/tag/allowscriptaccess-bypass/ so for embedding files it might not be as simple as setting the embed html param allowscriptaccess=never.

[Hugh Davenport (hugh-davenport)]

wrong bug

[Robert Lyon (robertl-9)]

I've put in a patch https://reviews.mahara.org/#/c/4292/ and from my initial tests it seems to work as expected.

For full testing one will need to test against all the different types of internalmedia one can embed as well as making sure other artefacts one can embed/download also still work as expected.

[Aaron Wells (u-aaronw)]

The patch 4292 looks good. Ready to include in the next release.

[Aaron Wells (u-aaronw)]

Reviewed patch 4292 again (after updates). Ready to merge.