XSS using user uploaded XHTML files

[Hugh Davenport]

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

[Hugh Davenport (hugh-davenport)]

I have confirmed this for all versions back to 1.2, database independant.

I have also tested using the /bin/bash approach (there was a bug with modern browsers using multifile uploads, which will be a seperate patch), and this also allows remote code execution.

For point 2, I would suggest the fixes 2 and 3. Fix 3 is enough for the revshell uploaded file, but not enough for the /bin/bash (or other shell) approach. Fix 2 solves this, as only allows an administrator with access to the config.php file to change the path to this file (as with pathtozip and pathtounzip, and since 1.5 pathtoaspell).

For the XSS, fix 1 should be sufficient.

I would avoid fix 4 at this stage, as the file layout has been this way for a long time, and doesn't have any direct impact to the fixing of the other bugs

Cheers,

Hugh

[Hugh Davenport (hugh-davenport)]

This patch disables automatic displaying of inline XHTML files, and instead escaped them with an option to download the original.

[Hugh Davenport (hugh-davenport)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

 status fixreleased
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iJwEAQECAAYFAlCbHO8ACgkQuMoJ2LQ3zxH8TAP/YN4BiCJZsn5a899/0UzV31Qg
lM8LXAwZWa6zFv6t0BQUHCqe6eFK9wPp51qgCWWXjUZ3vvvVcsyeWp6626aBFKSU
pCQXI9E7huPw802nJQ9WcZXRBUmgw87ww72Tx4mybnu7SPSrkZgXdnPGSMwDs89N
oWvTpl7Xuac48e6p0lU=
=ouU+
-----END PGP SIGNATURE-----