> > 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.
> Many times, but that's not necessarily clear or simple. The generic
> delta-generation tools we've tried in the past just choke on our files; note
> that the full-history dump of English Wikipedia -- the one we're most concerned
> about having archival copies of available -- is over 350 gigabytes uncompressed.
Actually, I just downloaded enwiki-20060518-pages-meta-history.xml.7z
and when I did a "7za l enwiki-20060518-pages-meta-history.xml.7z" it
said that the archive would be 692686106434 bytes (645 GB)
uncompressed. Is that inaccurate?
~MDD4696
Hello
I asked sometime ago about the possibilities to add some Thread
functionality to the discussion pages and I was pointed out that there
exists
http://meta.wikimedia.org/wiki/Talk:LiquidThreads.
However it seems to me not a very vivid project. Are there any other
plans to add such a functionality?
Thanks
Uwe Brauer
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Between other things I've been working on a distributed bzip2 compression tool
which could help speed up generation of data dumps.
By trading LAN bandwidth for idle CPU elsewhere in the server cluster, an
order-of-magnitude improvement in throughput seems reasonably practical; this
could cut bzip2 compression time for the large English Wikipedia history dumps
by a full day.
Status/documentation:
http://www.mediawiki.org/wiki/dbzip2
Source:
http://svn.wikimedia.org/viewvc/mediawiki/trunk/dbzip2
Updates on my (*blush*) development blog:
http://leuksman.com/
I'm hoping something similar can be accomplished with 7zip as well...
- -- brion vibber (brion @ pobox.com)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFEfVkSwRnhpk1wk44RAv/wAJ9JJghnGX6wmPvVz8lX6WLa+sfeZwCg1wex
ZcadcVpBCsZP866C4gdG7/M=
=SpCq
-----END PGP SIGNATURE-----
Hi.
Using MediaWiki v1.4.rc1 with mySQL 3.23.58, I get this error message
when trying
to search any word with MediaWiki search functionality:
-----------
A database query syntax error has occurred. This may indicate a bug in
the software. The last attempted database query was:
SELECT cur_id, cur_namespace, cur_title, cur_text FROM
`cur`,`searchindex` WHERE cur_id=si_page AND MATCH(si_title)
AGAINST('+foo' IN BOOLEAN MODE) AND cur_namespace IN (0) LIMIT 0,20
from within function "". MySQL returned error "1064: You have an error
in your SQL syntax near 'BOOLEAN MODE) AND cur_namespace IN (0) LIMIT
0,20 ' at line 1 (localhost)".
------------------
Any similar experience?
An automated run of parserTests.php showed the following failures:
Running test Table security: embedded pipes (http://mail.wikipedia.org/pipermail/wikitech-l/2006-April/034637.html)... FAILED!
Running test Link containing double-single-quotes '' (bug 4598)... FAILED!
Running test BUG 1887, part 2: A <math> with a thumbnail- math enabled... FAILED!
Running test Language converter: output gets cut off unexpectedly (bug 5757)... FAILED!
Running test HTML bullet list, unclosed tags (bug 5497)... FAILED!
Running test HTML ordered list, closed tags (bug 5497)... FAILED!
Running test HTML ordered list, unclosed tags (bug 5497)... FAILED!
Running test HTML nested bullet list, open tags (bug 5497)... FAILED!
Running test HTML nested ordered list, closed tags (bug 5497)... FAILED!
Running test HTML nested ordered list, open tags (bug 5497)... FAILED!
Passed 324 of 334 tests (97.01%) FAILED!
Hi All,
There is a mouseover user-specified JavaScript execution vulnerability
affecting MediaWiki 1.6.6 when running with two specific extensions.
One of those extension is installed on the Wikipedia, but the other is
not. Therefore the Wikipedia (and most MediaWiki installations) are
not affected.
Details have been provided to security(a)wikimedia.org as per the
instructions at: http://www.mediawiki.org/wiki/Security , and will be
made public in due course at: http://nickj.org/MediaWiki
All the best,
Nick.