** Changed in: mahara Status: In Progress => Fix Released -- You received this bug notification because you are a member of Mahara Contributors, which is subscribed to Mahara. https://bugs.launchpad.net/bugs/1055232
Title: XSS using user uploaded XHTML files Status in Mahara ePortfolio: Fix Released Status in Mahara 1.4 series: Fix Released Status in Mahara 1.5 series: Fix Released Bug description: Hello Maraha people, Issues: I have discovered 2 issues that in combination could result in remote code exec on a Mahara site. To get remote code exec the administrator would have to visit a page created on the site by a malicious user. In my opinion both issues would qualify as "Critical", obviously that judgement is up to you :) 1. The first issue is an XSS caused by inline display of files uploaded with the xhtml extension. An XML file can be uploaded with the extension xhtml and it will be displayed inline, without the sanitisation that is applied to html. This XML file can reference an XSL style that causes the XML to be rendered as HTML and the XSL can include JavaScript, resulting in XSS. 2. The ability of the administrator to set the path to clamav can be abused. For instance changing the path to clamav from '/path/to/av' to '/path/to/maharadata/artefact/file/originals/9/9' can cause a malicious uploaded file to be executed. This second bug is under bug #1057238 Proof of concept, (example files attached): 1. attacker uploads revshell.sh, notes its file-id (as generated by mahara) 2. attacker edits the XSL file so the payload will set the clamav path to the location of previously uploaded revshell.sh 3. attacker uploads XSL, notes its file-id 4. attacker edits the XML file, setting it to reference the file-id of the previously uploaded XSL 5. attacker uploads XML file 5. admin views the malicious XML page 6. path to clamav has now been set via XSS, to the attackers script 7. when attacker uploads a new file, the attackers script is run and attacker gets a reverse shell as www-data Fixes: 1. For the XSS, make sure only files that can be sanitized are displayed inline. 2. Because installing antivirus will require shell access to the server it seems reasonable to require setting the path to the AV be done in a configuration file rather than a settings page. It could be argued that in web applications generally, admin web access should not be equivalent to shell access, due to relatively ease of session compromise (as compared to shell access). 3. Uploaded files should not be set to executable. 4. Uploaded files should ideally be in a non-predicable location. Errata: 1. In the PoC the uploaded file is executed but another method could be to simply set the clamav path to /bin/bash so that any uploaded file would effectively be run as though it were a bash script. This would eliminate the need for an attacker to know the path to the maharadata directory and eliminate the need for the uploaded file to be executable. 2. Tested on Mahara 1.5.3 and Ubuntu Lucid Cheers, Mike To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1055232/+subscriptions _______________________________________________ Mailing list: https://launchpad.net/~mahara-contributors Post to : mahara-contributors@lists.launchpad.net Unsubscribe : https://launchpad.net/~mahara-contributors More help : https://help.launchpad.net/ListHelp