There is a
mouseover user-specified JavaScript execution vulnerability
affecting MediaWiki 1.6.6 when running with two specific extensions.
Specifically this is with the experimental <sort> extension. Nobody should be
using that one just yet, as it's still under development.
Superficially, yes, that's correct.
However, on a deeper level *maybe* it misses something. Specifically,
this problem wasn't found by automated testing.
Rather, it was found by noticing the automated testing was finding
problems with nested extension calls, and then suspecting that there
was a deeper problem with the interaction between nested extension
calls. The fact that such a problem was then found by hand leads me to
wonder whether this hypothesis is correct.
In other words, this seems like it *might* be systemic in nested
extension calls, rather than a one-off.
For example, suppose a site has extensions A and B installed.
Now suppose a user does something like this:
<a><b arg="something"></a>
(i.e. Makes a nested call to extension B inside extension A.)
or this:
<a><a arg="something"></a>
(i.e. makes a nested call to extension A instead extension A.)
Calls to extensions inside wiki text are special, and from the Parser
output it's clear they're treated specially, in that they seem to have
different precedence.
Currently extension A has to do lots of checking of the input to
prevent this kind of thing from being a problem. Example:
http://nickj.org/MediaWiki/Parser26 which abused a call to the ref
extension inside a call to the ref extension. Your fix is here:
http://mail.wikipedia.org/pipermail/mediawiki-cvs/2006-May/015379.html
; But the potentially worrying bit was that it only addresses that
specific extension.
So that was Ref + Ref.
Besides this problem, there are others:
http://nickj.org/MediaWiki/Parser31 , which is Inputbox + Math.
http://nickj.org/MediaWiki/Parser28-variant1 , which is Sort + Math.
And of course this one, which is Sort + something.
*Maybe* (and this goes back to the thing of formally specifying what's
allowed in wiki text) nested calls to extensions should be ignored by
the parser.
Or, failing that, maybe the inner call should have to complete, and
then the outer should be called - whereas I suspect *maybe* sometimes
the outer is called first, and then the inner is called second, which
potentially is where some of these things are coming from.
Either option would allow extension authors have to worry less about
bad input (by making it more the Parser's problem than the extension's
problem).
Of course, I could be wrong.
All the best,
Nick.