Page MenuHomePhabricator

XSS in SyntaxHighlight_GeSHi
Closed, ResolvedPublic

Description

Reported by Mateusz Goik. The example.php script is writing out PHP_SELF unfiltered, so this should be an XSS, although I'm not able to reproduce it on enwiki or my local dev environment. I think apache is rewriting things enough to prevent it. But we should still fix it asap.

Hi,

XSS in extensions/SyntaxHighlight_GeSHi/geshi/contrib/example.php

PoC:

http://localhost/wiki/extensions/SyntaxHighlight_GeSHi/geshi/contrib/example.php/"><img
src="asd" onerror="alert(1);">

HTML:

"<form action=""><img onerror="alert(1);" src="asd">" method="post"&gt;
<h3>Source to highlight</h3>
<p>
<textarea id="source" name="source" cols="60" rows="10"></textarea>
</p>
<h3>Choose a language</h3>
<p>"


Version: master
Severity: normal

Details

Reference
bz49070

Event Timeline

bzimport raised the priority of this task from to High.Nov 22 2014, 1:43 AM
bzimport added a project: SyntaxHighlight.
bzimport set Reference to bz49070.
bzimport added a subscriber: Unknown Object (MLST).

Can you actually replicate this? I couldn't locally, and trying to access the example.php file just downloaded it on wikipedia

I should note that I have upstream commit access to the GeSHi repository, and hopefully can make movement to get a release out too

Created attachment 12442
urlencode PHP_SELF in form's action

Attached:

Sam, can you check if this patch seems reasonable, and I'll deploy it? I think it's remote enough it won't cause merge conflicts for anyone.

(In reply to comment #3)

Sam, can you check if this patch seems reasonable, and I'll deploy it? I
think
it's remote enough it won't cause merge conflicts for anyone.

I've notified upstream to see how they want to handle it from their end.

I'm not sure there's anything to push to site for this issue. Attempting to visit [1] results the php file being downloaded, rather than executed. I'm not sure the cluster is vulnerable to the issue

[1] http://en.wikipedia.org/w/extensions/SyntaxHighlight_GeSHi/geshi/contrib/example.php

Yep, you are correct, no patching needed. Let us know what they say. Thanks!

From upstream, would seem like there's a bit of text missing:
"Hi Sam,

thank you for disclosing this vulnerability. First off, let's start with
the patch:

$ svn diff

Index: example.php

  • --- example.php (Revision 2572)

+++ example.php (Arbeitskopie)
@@ -169,7 +169,7 @@

echo '<hr />';

}
?>

  • -<form action="<?php echo basename($_SERVER['PHP_SELF']); ?>"

method="post">
+<form action="?" method="post">
<h3>Source to highlight</h3>
<p>
<textarea rows="10" cols="60" name="source" id="source"><?php echo
$fill_source ? htmlspecialchars($_POST['source']) : '' ?></textarea>

Now on to the actual issue: Usually you aren't supposed to have the
contrib directory on your production system. Taken in addition that this
is a non-permanent XSS (if it really is) there's no direct risk for a
user unless tricked to click a prepared link.

Hope the intension of the above patch is clear.

Best regards,
BenBE."

Seems a bit weird to me to include the dir in tarballs. Anyway

https://gerrit.wikimedia.org/r/68863 - Removed the contrib dir, and added a gitignore against it. Easier done in git than SVN when it was included via a svn external.

I'm not sure if we should just close this bug as is, with the offending files removed

(In reply to comment #6 by Reedy)

https://gerrit.wikimedia.org/r/68863 - Removed the contrib dir, and added a
gitignore against it. I'm not sure if we should just close this bug as is,
with the offending files removed

Chris: Shall we close this ticket on our side? And can we move this out of the "Security" product, as per comment 6 from upstream?

This was assigned CVE-2013-4305