Activity log for bug #1055232

Date Who What changed Old value New value Message
2012-09-24 01:02:35 Hugh Davenport bug added bug
2012-09-24 01:04:02 Hugh Davenport bug added subscriber Bug Hunter
2012-09-24 01:04:21 Hugh Davenport mahara: milestone 1.6.0
2012-09-24 01:04:53 Hugh Davenport nominated for series mahara/1.5
2012-09-24 01:04:53 Hugh Davenport bug task added mahara/1.5
2012-09-24 01:05:15 Hugh Davenport mahara/1.5: status New Confirmed
2012-09-24 01:05:17 Hugh Davenport mahara/1.5: assignee Hugh Davenport (hugh-catalyst)
2012-09-24 01:05:26 Hugh Davenport nominated for series mahara/1.4
2012-09-24 01:05:26 Hugh Davenport bug task added mahara/1.4
2012-09-24 01:05:32 Hugh Davenport mahara/1.4: status New Confirmed
2012-09-24 01:05:34 Hugh Davenport mahara/1.4: assignee Hugh Davenport (hugh-catalyst)
2012-09-24 01:07:03 Hugh Davenport attachment added revshell.sh https://bugs.launchpad.net/mahara/+bug/1055232/+attachment/3336298/+files/revshell.sh
2012-09-24 01:07:15 Hugh Davenport attachment added change-clampath-xsl.xhtml https://bugs.launchpad.net/mahara/+bug/1055232/+attachment/3336299/+files/change-clampath-xsl.xhtml
2012-09-24 01:08:08 Hugh Davenport attachment added change-clampath-xml.xhtml https://bugs.launchpad.net/mahara/+bug/1055232/+attachment/3336300/+files/change-clampath-xml.xhtml
2012-09-24 01:27:31 Hugh Davenport attachment added bug-1055232-2.patch https://bugs.launchpad.net/mahara/+bug/1055232/+attachment/3336352/+files/bug-1055232-2.patch
2012-09-24 01:32:04 Hugh Davenport attachment added bug-1055232-3.patch https://bugs.launchpad.net/mahara/+bug/1055232/+attachment/3336372/+files/bug-1055232-3.patch
2012-09-24 02:34:46 Hugh Davenport attachment added bug-1055232-1.patch https://bugs.launchpad.net/mahara/+bug/1055232/+attachment/3336480/+files/bug-1055232-1.patch
2012-09-24 02:49:46 Hugh Davenport attachment added bug-1055232-2-14.patch https://bugs.launchpad.net/mahara/+bug/1055232/+attachment/3336522/+files/bug-1055232-2-14.patch
2012-09-24 02:50:43 Hugh Davenport attachment added bug-1055232-3-14.patch https://bugs.launchpad.net/mahara/+bug/1055232/+attachment/3336523/+files/bug-1055232-3-14.patch
2012-09-24 02:53:15 Hugh Davenport attachment added bug-1055232-2-12.patch https://bugs.launchpad.net/mahara/+bug/1055232/+attachment/3336524/+files/bug-1055232-2-12.patch
2012-09-24 03:37:16 Hugh Davenport attachment added bug-1055232-3-master-upgrade.patch https://bugs.launchpad.net/mahara/+bug/1055232/+attachment/3336615/+files/bug-1055232-3-master-upgrade.patch
2012-09-24 03:37:34 Hugh Davenport attachment added bug-1055232-3-16-upgrade.patch https://bugs.launchpad.net/mahara/+bug/1055232/+attachment/3336616/+files/bug-1055232-3-16-upgrade.patch
2012-09-24 03:37:53 Hugh Davenport attachment added bug-1055232-3-15-upgrade.patch https://bugs.launchpad.net/mahara/+bug/1055232/+attachment/3336617/+files/bug-1055232-3-15-upgrade.patch
2012-09-24 03:38:11 Hugh Davenport attachment added bug-1055232-3-14-upgrade.patch https://bugs.launchpad.net/mahara/+bug/1055232/+attachment/3336618/+files/bug-1055232-3-14-upgrade.patch
2012-09-24 03:38:25 Hugh Davenport attachment added bug-1055232-3-12-upgrade.patch https://bugs.launchpad.net/mahara/+bug/1055232/+attachment/3336619/+files/bug-1055232-3-12-upgrade.patch
2012-09-27 01:44:48 Hugh Davenport 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. 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 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
2012-09-27 01:46:28 Hugh Davenport summary XSS + design flaw = remote code exec XSS using user uploaded XHTML files
2012-09-27 01:46:30 Hugh Davenport mahara: importance Undecided Critical
2012-09-27 01:46:31 Hugh Davenport mahara/1.4: importance Undecided Critical
2012-09-27 01:46:33 Hugh Davenport mahara/1.5: importance Undecided Critical
2012-09-27 01:49:33 Hugh Davenport mahara: status Confirmed In Progress
2012-09-27 01:49:35 Hugh Davenport mahara/1.4: status Confirmed In Progress
2012-09-27 01:49:37 Hugh Davenport mahara/1.5: status Confirmed In Progress
2012-09-27 02:40:37 Hugh Davenport cve linked 2012-2243
2012-10-10 03:03:12 Melissa Draper visibility private public
2012-10-10 03:03:33 Melissa Draper mahara/1.5: milestone 1.5.4
2012-10-10 03:45:39 Melissa Draper mahara/1.5: status In Progress Fix Released
2012-10-10 03:48:10 Melissa Draper mahara/1.4: milestone 1.4.5
2012-10-10 04:18:28 Melissa Draper mahara/1.4: status In Progress Fix Released
2012-10-23 22:49:44 Hugh Davenport mahara: status In Progress Fix Released