headers
Nick Jenkins | 3 Apr 2006 05:31
Picon
Gravatar

Re: Towards arbitrary client-side JavaScript execution

> > * Why does MediaWiki ever allow unescaped ">" characters? This
> > behaviour seem to increase the chances of a JavaScript security
> > problem.
>
> It doesn't, modulo uncaught bugs.

Well, all I can tell you is that this is the behaviour that I observe.

But you don't have to take my word for it; see for yourself here:
* Unescaped ">" characters in the HTML output:
http://nickj.org/MediaWiki/Parser11
* Wiki Source: http://nickj.org/Special:Export/MediaWiki/Parser11
* Site is running MediaWiki 1.5.6: http://nickj.org/Special:Version

Note that I'm looking at the Parser purely from a black-box-testing
perspective: I give it certain input, and observe what it does. I'm
not looking at it from a source-code or design-level perspective (i.e.
what it should do). Then as a human, I automatically try to spot the
patterns in the behaviour that I observe, and from that construct a
mental model that explains what the Parser is doing. And currently
that says: the ">" character does not appear to be escaped until after
the "<" character is used.

Disclaimer: I have modified the MediaWiki source of this installation
a little, but only to add limited ACLs, and change 2 or 3 minor things
in the default page layout that I disliked. As far as I am aware,
nothing that I have changed will modify the behaviour of the Parser
(but of course, I could be wrong).

> This is thanks to the wacky multi-pass parser. As a quick hack-around:
(Continue reading)

Permalink | Reply |
headers
Brion Vibber | 3 Apr 2006 11:15
Picon
Favicon
Gravatar

Re: Towards arbitrary client-side JavaScript execution

Nick Jenkins wrote:
> ------------------------------------
> {|
> | |[ftp://|x||]" onmouseover="alert(document.cookie)">test
> ------------------------------------

I've tossed in a quick tweak to the table parser to reduce the danger of this;
it'll now attempt to do the || split only outside of tags. The above example
still ends up with bad nesting (not well-formed XML output) but there's nothing
injected into the attribute area.

(It might also make sense to move the table translation several steps up, before
the various link parsing. In theory, we can think of it as a transformation from
one wiki-markup to another wiki-markup bit. Probably we'll want a bigger set of
test cases for tables, however; anyone want to scour the help pages and
infoboxes and such?)

-- brion vibber (brion  <at>  pobox.com)


_______________________________________________
Wikitech-l mailing list
Wikitech-l@...
http://mail.wikipedia.org/mailman/listinfo/wikitech-l
Permalink | Reply |
headers
Nick Jenkins | 3 Apr 2006 10:53
Picon
Gravatar

Re: Towards arbitrary client-side JavaScript execution

> Are you keeping up to date with the code?

Probably not!

Let me see if I can repo with latest stable, 1.5.8:

# wget -q http://superb.dl.sourceforge.net/sourceforge/wikipedia/mediawiki-1.5.8.tar.gz
# tar zfx mediawiki-1.5.8.tar.gz
# mv wiki old-wiki
# mv mediawiki-1.5.8 wiki
# cp old-wiki/LocalSettings.php wiki

[[UsesOpenTag]] contains:
----------------------------
>>>>>>>
{{OpenTag}}
>>>>>>>
----------------------------

Output is:
----------------------------
<p>>>>>>>>

</p>
<table bgcolor="<span">

>>>>>>>
</table>
----------------------------
(Continue reading)

Permalink | Reply |
headers
Nick Jenkins | 4 Apr 2006 08:50
Picon
Gravatar

Re: Towards arbitrary client-side JavaScript execution

> Well, upgrading would be nice. :)

What, and give up on Debian Woody?! Why, I've still got exactly 27
days of security support left, until (after 4 years) even the Debian
folks finally abandon it! ;-)

I'm currently holding out for Ubuntu 6.06 to be released (5 years of
support on the server - very nice)

> We're junking CVS

Cool, and I see that
http://www.mediawiki.org/wiki/Template:MW_quick_download (which is
what mislead me to be looking at CVS) has been updated to point to SVN
instead.

> That'd be 1.6.0 as of tomorrow or shortly thereafter.

Sounds good, although from a quick glance the 1.6 /HISTORY, /UPGRADE
and /INSTALL readme text files seemed to be assuming 1.5 (maybe).

> I've tossed in a quick tweak to the table parser to reduce the danger of this;

Thank you!

> That's before the fixes checked in on head (which will go into 1.5.9 also).

OK, well the new stuff below is still based on 1.5.8, so these things
may or may not be resolved by the fixes that have already been checked
in (my apologies if they are):
(Continue reading)

Permalink | Reply |
headers
Nick Jenkins | 7 Apr 2006 08:22
Picon
Gravatar

Re: Towards arbitrary client-side JavaScript execution

> Also, one other bit of strangeness:
> ---------------------------------
> {|
> | http://a|
> ---------------------------------
>
> HTML output:
> ---------------------------------
> <table>
> <tr>
> <td>" class='external free' title="http://a|" rel="nofollow">http://a|</a>
> ---------------------------------
> Note that somewhere along the line the Parser eats the '<a
> href="http://a' string. Available online at
> http://nickj.org/MediaWiki/Parser13

Similar to the above is this:
--------------------------
{|
!https://||||||
--------------------------

Which in MediaWiki 1.6.1 also eats the "<a href" part, giving:
--------------------------
<table>
<tr>
<th>|||||" class='external free' title="https://||||||"
rel="nofollow">https://</th><th></th><th></th><th></a>
--------------------------
(Continue reading)

Permalink | Reply |
headers
Brion Vibber | 3 Apr 2006 11:11
Picon
Favicon
Gravatar

Re: Towards arbitrary client-side JavaScript execution

Nick Jenkins wrote:
> So I get the same behaviour with 1.5.8 - which I believe is the most
> up to date released version that I can get.

That's before the fixes checked in on head (which will go into 1.5.9 also).

> Exactly how "up to date" do you mean? If you're talking CVS-checkout
> up-to-date, then no, I'm not up to date. But neither are most people,
> I daresay. What I'm personal interested in is the behaviour of
> released available-now production-ready-here-and-now
> latest-and-greatest-stable-version software, for the simple reason
> that that's the software I know I'll use.

That'd be 1.6.0 as of tomorrow or shortly thereafter.

> However, undeterred, I checked out from CVS following the cvs checkout
> instructions on http://www.mediawiki.org/wiki/Download_from_CVS :

We're junking CVS due to longtime problems and a total outage for the last few
days; grab current code from Subersion.
http://www.mediawiki.org/wiki/Subversion

> Completely ignoring the directions, I tried to use it anyway, but got
> various errors. No big surprise, but it didn't hurt to try. So, short
> of upgrading the system I'm using, it's as up-to-date as can be.

Well, upgrading would be nice. :)

-- brion vibber (brion  <at>  pobox.com)
(Continue reading)

Permalink | Reply |
headers
Brion Vibber | 3 Apr 2006 09:21
Picon
Favicon
Gravatar

Re: Towards arbitrary client-side JavaScript execution

Nick Jenkins wrote:
>>> * Why does MediaWiki ever allow unescaped ">" characters? This
>>> behaviour seem to increase the chances of a JavaScript security
>>> problem.
>> It doesn't, modulo uncaught bugs.
> 
> Well, all I can tell you is that this is the behaviour that I observe.

That's why they're called "bugs".

> Question: will this break wikis with $wgRawHtml on? (Used to embed
> arbitrary HTML.)

Arbitrary HTML, by being arbitrary, does not have attribute normalization
applied to it.

> Instead, we now have one article, and one template. For the template
> (call it "Template:OpenTag") we have:
> ------------------------------------
> {| BGCOLOR=<span style="font-weight: bold;">
> ------------------------------------
> 
> Then in the article we have:
> ------------------------------------
> {{OpenTag}}
> ------------------------------------
> 
> Which now renders as this HTML output:
> ------------------------------------
> <p>>>>>>
(Continue reading)

Permalink | Reply |
headers
Nick Jenkins | 31 Mar 2006 08:04
Picon
Gravatar

Towards arbitrary client-side JavaScript execution

Aim
===

To see if it's possible to execute arbitrary client-side JavaScript,
using MediaWiki as the delivery system.

Background
==========

To execute arbitrary JavaScript, we mostly need to find a way to get
MediaWiki to allow us to open a tag ("<script"), and to close a tag
(">"). In particular, we need some form of wiki input text that will
produce this as the rendered HTML output.

The MediaWiki parser seems to try to prevent both of these things, by
escaping "<" and ">" characters. For example, if you give it wiki
input like this:
---------------------------------------------------------
<"hello world">
---------------------------------------------------------

Then you get back this HTML:
---------------------------------------------------------
&lt;"hello world"&gt;
---------------------------------------------------------

However, the parser is not perfect. There are some inputs that will
give unescaped ">" or "<" back.

The trick is probably to combine these omissions together, in such a
(Continue reading)

Permalink | Reply |
headers
Steve Bennett | 31 Mar 2006 10:47
Picon

Re: Towards arbitrary client-side JavaScript execution

On 3/31/06, Nick Jenkins <nickpj@...> wrote:
> The MediaWiki parser seems to try to prevent both of these things, by
> escaping "<" and ">" characters. For example, if you give it wiki
> input like this:

Hi Nick - very interesting post :) I don't know anything of how
MediaWiki works, but I'm curious why you're allowed HTML of the form
<U>aoeu</U>. How does that work, and will that help your nefarious
goal?

Steve
Permalink | Reply |
headers
Brion Vibber | 31 Mar 2006 09:57
Picon
Favicon
Gravatar

Re: Towards arbitrary client-side JavaScript execution

Nick Jenkins wrote:
> ---------------------------------------------------------
> {| WIDTH=[[image:ftp://~
> {| ALIGN='''~~~</math>
> {| BGCOLOR=<span style="font-weight: bold;">
> ---------------------------------------------------------
> 
> Which will give this HTML output:
> ---------------------------------------------------------
> <table width="&#91;&#91;image:<a" class="external free" title="ftp&#58;//~">
> <table align="<b><!--LINK">
> <table bgcolor="<span">
> ---------------------------------------------------------

This is thanks to the wacky multi-pass parser. As a quick hack-around:

--- includes/Sanitizer.php.prev	2006-03-30 23:50:58.000000000 -0800
+++ includes/Sanitizer.php	2006-03-30 23:48:59.000000000 -0800
 <at>  <at>  -577,6 +577,9  <at>  <at> 
 			# Templates and links may be expanded in later parsing,
 			# creating invalid or dangerous output. Suppress this.
 			$value = strtr( $value, array(
+				'<'    => '&lt;',   // This should never happen,
+				'>'    => '&gt;',   // we've received invalid input
+				'"'    => '&quot;', // which should have been escaped.
 				'{'    => '&#123;',
 				'['    => '&#91;',
 				"''"   => '&#39;&#39;',

If SourceForge's CVS were working, this would be committed by now. (Thanks
(Continue reading)

Permalink | Reply |
headers
Brion Vibber | 31 Mar 2006 09:25
Picon
Favicon
Gravatar

Re: Towards arbitrary client-side JavaScript execution

Nick Jenkins wrote:
> * Why does MediaWiki ever allow unescaped ">" characters? This
> behaviour seem to increase the chances of a JavaScript security
> problem.

It doesn't, modulo uncaught bugs.

-- brion vibber (brion  <at>  pobox.com)


_______________________________________________
Wikitech-l mailing list
Wikitech-l@...
http://mail.wikipedia.org/mailman/listinfo/wikitech-l
Permalink | Reply |

Gmane