Comment 0 for bug 1055232

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