Mailing List Archive

MediaWiki security release 1.16.4
Our patch for the Internet Explorer 6 XSS issue (bug 28235) released
two days ago in 1.16.3 was insufficient to fix that bug. The original
reporter, Masato Kinugawa, pointed out the flaw on bug 28507. So we
are doing another release, which contains a second attempt at fixing
the issue.

Apologies to everyone for the inconvenience. Big thanks go to Masato
Kinugawa for helping to keep MediaWiki secure. Thanks also to Roan
Kattouw who helped me test the patch this time around, so that we can
hopefully avoid a repeat.

It is necessary to upgrade MediaWiki to avoid an XSS vulnerability for
Internet Explorer clients, version 6 and earlier. Also, if you used
the Apache configuration I suggested in the previous release
announcement, you should update it to:

RewriteEngine On
RewriteCond %{QUERY_STRING} \.[a-z0-9]{1,4}(#|\?|$) [nocase]
RewriteRule . - [forbidden]


We missed the fact that there can be more than one question mark in a
URL. In certain circumstances, IE 6 will use a file extension
immediately before a question mark character, regardless of how many
question marks precede it. For example, with the URL:

http://example.com/a?b?c.html?d?e

IE 6 will see the file extension as ".html".

**********************************************************************
Download:
http://download.wikimedia.org/mediawiki/1.16/mediawiki-1.16.4.tar.gz

Patch to previous version (1.16.3):
http://download.wikimedia.org/mediawiki/1.16/mediawiki-1.16.4.patch.gz

GPG signatures:
http://download.wikimedia.org/mediawiki/1.16/mediawiki-1.16.4.tar.gz.sig
http://download.wikimedia.org/mediawiki/1.16/mediawiki-1.16.4.patch.gz.sig

Public keys:
https://secure.wikimedia.org/keys.html


_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: MediaWiki security release 1.16.4 [ In reply to ]
On 14.04.2011 09:47, Tim Starling wrote:
> We missed the fact that there can be more than one question mark in a
> URL. In certain circumstances, IE 6 will use a file extension
> immediately before a question mark character, regardless of how many
> question marks precede it. For example, with the URL:
>
> http://example.com/a?b?c.html?d?e
>
> IE 6 will see the file extension as ".html".

Wow, seriously? IE6 should be taken out the back and shot...

-- daniel

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Dropping IE6 support (was: MediaWiki security release 1.16.4) [ In reply to ]
On 14-04-11 10:02 Daniel Kinzler <daniel@brightbyte.de> wrote:


>Wow, seriously? IE6 should be taken out the back and shot...

You're in luck. These days, even Microsoft agrees with you:

http://www.ie6countdown.com/

So when will we be able to drop IE6 support in MediaWiki completely? What
metrics/thresholds can we use?

I would suggest to set a percentage of worldwide usage as reported by some
"trusted" statistics reported, or possibly a percentage of Wikimedia
pageviews. 3% or 4%?

Any thoughts?

Siebrand



_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Dropping IE6 support (was: MediaWiki security release 1.16.4) [ In reply to ]
2011/4/14 Siebrand Mazeland <s.mazeland@xs4all.nl>:
> So when will we be able to drop IE6 support in MediaWiki completely? What
> metrics/thresholds can we use?
>
IMO there's a difference between no longer supporting IE6 and no
longer protecting IE6 users from XSS attacks.

> I would suggest to set a percentage of worldwide usage as reported by some
> "trusted" statistics reported, or possibly a percentage of Wikimedia
> pageviews. 3% or 4%?
>
At least for JavaScript feature development, our unofficial cutoff for
"we're not gonna spend any time on this browser, if it works, great,
if it doesn't, tough luck" is 0.5%. However, that's just for JS
enhancements; it's my opinion that at least reading Wikipedia should
be possible (i.e. not severely broken) in almost every browser.

Roan Kattouw (Catrope)

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Dropping IE6 support [ In reply to ]
On 14.04.2011 11:10, Siebrand Mazeland wrote:
> On 14-04-11 10:02 Daniel Kinzler <daniel@brightbyte.de> wrote:
>
>> Wow, seriously? IE6 should be taken out the back and shot...
>
> You're in luck. These days, even Microsoft agrees with you:
>
> http://www.ie6countdown.com/

Aw man, someone please spoof this website and replace "Internet Explorer 6" with
just "Internet Explorer", and make the download link point to firefox.

msiecountdown.com is still free...

-- daniel

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Dropping IE6 support [ In reply to ]
Hi,

Le jeudi 14 avril 2011 11:21:57, Daniel Kinzler a écrit :
> On 14.04.2011 11:10, Siebrand Mazeland wrote:
> > On 14-04-11 10:02 Daniel Kinzler <daniel@brightbyte.de> wrote:
> >> Wow, seriously? IE6 should be taken out the back and shot...
> >
> > You're in luck. These days, even Microsoft agrees with you:
> >
> > http://www.ie6countdown.com/
>
> Aw man, someone please spoof this website and replace "Internet Explorer 6"
> with just "Internet Explorer", and make the download link point to
> firefox.
>
> msiecountdown.com is still free...

On a related note: http://theie9countdown.com

--
Guillaume Paumier

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Dropping IE6 support [ In reply to ]
On 14.04.2011 11:46, Guillaume Paumier wrote:
> Hi,
>>> You're in luck. These days, even Microsoft agrees with you:
>>>
>>> http://www.ie6countdown.com/
>>
>> Aw man, someone please spoof this website and replace "Internet Explorer 6"
>> with just "Internet Explorer", and make the download link point to
>> firefox.
>>
>> msiecountdown.com is still free...
>
> On a related note: http://theie9countdown.com
>
hahaha thank you!

-- daniel

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Dropping IE6 support (was: MediaWiki security release 1.16.4) [ In reply to ]
Hoi,
The people with IE6 have disproportionally problems with reading Wikipedia
in their mother tongue and IE6 can be found particularly in the "global
south". Also CommScore numbers are unlikely to see this potential.

The question is not should we support IE6, it is just that I wonder about
what our numbers show.
Thanks,
GerardM

On 14 April 2011 11:14, Roan Kattouw <roan.kattouw@gmail.com> wrote:

> 2011/4/14 Siebrand Mazeland <s.mazeland@xs4all.nl>:
> > So when will we be able to drop IE6 support in MediaWiki completely? What
> > metrics/thresholds can we use?
> >
> IMO there's a difference between no longer supporting IE6 and no
> longer protecting IE6 users from XSS attacks.
>
> > I would suggest to set a percentage of worldwide usage as reported by
> some
> > "trusted" statistics reported, or possibly a percentage of Wikimedia
> > pageviews. 3% or 4%?
> >
> At least for JavaScript feature development, our unofficial cutoff for
> "we're not gonna spend any time on this browser, if it works, great,
> if it doesn't, tough luck" is 0.5%. However, that's just for JS
> enhancements; it's my opinion that at least reading Wikipedia should
> be possible (i.e. not severely broken) in almost every browser.
>
> Roan Kattouw (Catrope)
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Dropping IE6 support (was: MediaWiki security release 1.16.4) [ In reply to ]
2011/4/14 Gerard Meijssen <gerard.meijssen@gmail.com>:
> Hoi,
> The people with IE6 have disproportionally problems with reading Wikipedia
> in their mother tongue and IE6 can be found particularly in the "global
> south". Also CommScore numbers are unlikely to see this potential.
>
> The question is not should we support IE6, it is just that I wonder about
> what our numbers show.

According to http://stats.wikimedia.org/wikimedia/squids/SquidReportClients.htm
, IE6 is 3.65% of our traffic. There is no per-country breakdown of
browsers that I know of, though, maybe Erik Z could be talked into
making one.

Roan Kattouw (Catrope)

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Dropping IE6 support (was: MediaWiki security release 1.16.4) [ In reply to ]
*For reading*, we aim to support any browser with 0.1%[1] use or more.

This has both culled things out, like IE 5.5, and surfaced things like NetFront (Sony Playstation Browser).

*For security*, if it's possible to protect the site or our users, and we have money in the bank, we should be doing what it takes to protect them.

*For everything else*, we support various browsers based on a variety of factors:

* Whether the browser can ever support the feature at all
* Level of difficulty getting the feature to work in the browser
* Level of resources dedicated to the project

We normally knock out the most commonly-used and easy-to-get-working browsers first, and then sort out details on other browsers in order of use. There's no base percentage here, just hopes and dreams.

- Trevor

[1] http://stats.wikimedia.org/wikimedia/squids/SquidReportClients.htm

On Apr 14, 2011, at 2:10 AM, Siebrand Mazeland wrote:

> On 14-04-11 10:02 Daniel Kinzler <daniel@brightbyte.de> wrote:
>
>
>> Wow, seriously? IE6 should be taken out the back and shot...
>
> You're in luck. These days, even Microsoft agrees with you:
>
> http://www.ie6countdown.com/
>
> So when will we be able to drop IE6 support in MediaWiki completely? What
> metrics/thresholds can we use?
>
> I would suggest to set a percentage of worldwide usage as reported by some
> "trusted" statistics reported, or possibly a percentage of Wikimedia
> pageviews. 3% or 4%?
>
> Any thoughts?
>
> Siebrand
>
>
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l


_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Mediawiki-l] MediaWiki security release 1.16.4 [ In reply to ]
Using the rewrite inside images/.htaccess appears to conflict with
existing installations with a root .htaccess including the code for the
thumbnail handler.

You won't notice it right away because most images will already have
existing thumbnails generated, but at some random point when someone.

In fact, I ONLY found out things were broken on any of my wiki after I
created a brand new wiki with similar config and found I got 404s
instead of thumbnails.

My fix was to comment out the code in images/.htaccess and add it to my
root .htaccess. Of course I'll need to do something else on another one
of my wiki that uses a separate domain for serving uploads.

~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]

On 11-04-14 12:47 AM, Tim Starling wrote:
> Our patch for the Internet Explorer 6 XSS issue (bug 28235) released
> two days ago in 1.16.3 was insufficient to fix that bug. The original
> reporter, Masato Kinugawa, pointed out the flaw on bug 28507. So we
> are doing another release, which contains a second attempt at fixing
> the issue.
>
> Apologies to everyone for the inconvenience. Big thanks go to Masato
> Kinugawa for helping to keep MediaWiki secure. Thanks also to Roan
> Kattouw who helped me test the patch this time around, so that we can
> hopefully avoid a repeat.
>
> It is necessary to upgrade MediaWiki to avoid an XSS vulnerability for
> Internet Explorer clients, version 6 and earlier. Also, if you used
> the Apache configuration I suggested in the previous release
> announcement, you should update it to:
>
> RewriteEngine On
> RewriteCond %{QUERY_STRING} \.[a-z0-9]{1,4}(#|\?|$) [nocase]
> RewriteRule . - [forbidden]
>
>
> We missed the fact that there can be more than one question mark in a
> URL. In certain circumstances, IE 6 will use a file extension
> immediately before a question mark character, regardless of how many
> question marks precede it. For example, with the URL:
>
> http://example.com/a?b?c.html?d?e
>
> IE 6 will see the file extension as ".html".
>
> **********************************************************************
> Download:
> http://download.wikimedia.org/mediawiki/1.16/mediawiki-1.16.4.tar.gz
>
> Patch to previous version (1.16.3):
> http://download.wikimedia.org/mediawiki/1.16/mediawiki-1.16.4.patch.gz
>
> GPG signatures:
> http://download.wikimedia.org/mediawiki/1.16/mediawiki-1.16.4.tar.gz.sig
> http://download.wikimedia.org/mediawiki/1.16/mediawiki-1.16.4.patch.gz.sig
>
> Public keys:
> https://secure.wikimedia.org/keys.html

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Mediawiki-l] MediaWiki security release 1.16.4 [ In reply to ]
Actually I also had to add a `RewriteCond %{REQUEST_FILENAME} ^/?images`
to prevent /index.php from being broken.

My root .htaccess looks something like this now:

RewriteEngine on

# Protect against bug 28235
RewriteCond %{REQUEST_FILENAME} ^/?images
RewriteCond %{QUERY_STRING} \.[a-z0-9]{1,4}(#|\?|$) [nocase]
RewriteRule . - [forbidden]

# Thumbnail handler for image thumbnails
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(/?)images/thumb/[0-9a-f]/[0-9a-f][0-9a-f]/([^/]+)/([0-9]+)px-.*$ $1thumb.php?f=$2&width=$3 [L,QSA]

# Thumbnail handler for archived images
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(/?)images/thumb/archive/[0-9a-f]/[0-9a-f][0-9a-f]/([^/]+)/([0-9]+)px-.*$ $1thumb.php?f=$2&width=$3&archived=1 [L,QSA]

# Handler for 404 pages
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^/?.*$ /index.php?title=Special:Error404
RewriteRule ^(/?)images/thumb/[0-9a-f]/[0-9a-f][0-9a-f]/([^/]+)/([0-9]+)px-.*$ $1thumb.php?f=$2&width=$3 [L,QSA]


I haven't figured out how to replicate that bug 28235 fix in Nginx though.

~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]

On 11-04-19 09:28 AM, Daniel Friesen wrote:
> Using the rewrite inside images/.htaccess appears to conflict with
> existing installations with a root .htaccess including the code for the
> thumbnail handler.
>
> You won't notice it right away because most images will already have
> existing thumbnails generated, but at some random point when someone.
>
> In fact, I ONLY found out things were broken on any of my wiki after I
> created a brand new wiki with similar config and found I got 404s
> instead of thumbnails.
>
> My fix was to comment out the code in images/.htaccess and add it to my
> root .htaccess. Of course I'll need to do something else on another one
> of my wiki that uses a separate domain for serving uploads.
>
> ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
>
> On 11-04-14 12:47 AM, Tim Starling wrote:
>> Our patch for the Internet Explorer 6 XSS issue (bug 28235) released
>> two days ago in 1.16.3 was insufficient to fix that bug. The original
>> reporter, Masato Kinugawa, pointed out the flaw on bug 28507. So we
>> are doing another release, which contains a second attempt at fixing
>> the issue.
>>
>> Apologies to everyone for the inconvenience. Big thanks go to Masato
>> Kinugawa for helping to keep MediaWiki secure. Thanks also to Roan
>> Kattouw who helped me test the patch this time around, so that we can
>> hopefully avoid a repeat.
>>
>> It is necessary to upgrade MediaWiki to avoid an XSS vulnerability for
>> Internet Explorer clients, version 6 and earlier. Also, if you used
>> the Apache configuration I suggested in the previous release
>> announcement, you should update it to:
>>
>> RewriteEngine On
>> RewriteCond %{QUERY_STRING} \.[a-z0-9]{1,4}(#|\?|$) [nocase]
>> RewriteRule . - [forbidden]
>>
>>
>> We missed the fact that there can be more than one question mark in a
>> URL. In certain circumstances, IE 6 will use a file extension
>> immediately before a question mark character, regardless of how many
>> question marks precede it. For example, with the URL:
>>
>> http://example.com/a?b?c.html?d?e
>>
>> IE 6 will see the file extension as ".html".
>>
>> **********************************************************************
>> Download:
>> http://download.wikimedia.org/mediawiki/1.16/mediawiki-1.16.4.tar.gz
>>
>> Patch to previous version (1.16.3):
>> http://download.wikimedia.org/mediawiki/1.16/mediawiki-1.16.4.patch.gz
>>
>> GPG signatures:
>> http://download.wikimedia.org/mediawiki/1.16/mediawiki-1.16.4.tar.gz.sig
>> http://download.wikimedia.org/mediawiki/1.16/mediawiki-1.16.4.patch.gz.sig
>>
>> Public keys:
>> https://secure.wikimedia.org/keys.html

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Mediawiki-l] MediaWiki security release 1.16.4 [ In reply to ]
Actually I also had to add a `RewriteCond %{REQUEST_FILENAME} ^/?images`
to prevent /index.php from being broken.

My root .htaccess looks something like this now:

RewriteEngine on

# Protect against bug 28235
RewriteCond %{REQUEST_FILENAME} ^/?images
RewriteCond %{QUERY_STRING} \.[a-z0-9]{1,4}(#|\?|$) [nocase]
RewriteRule . - [forbidden]

# Thumbnail handler for image thumbnails
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule
^(/?)images/thumb/[0-9a-f]/[0-9a-f][0-9a-f]/([^/]+)/([0-9]+)px-.*$
$1thumb.php?f=$2&width=$3 [L,QSA]

# Thumbnail handler for archived images
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule
^(/?)images/thumb/archive/[0-9a-f]/[0-9a-f][0-9a-f]/([^/]+)/([0-9]+)px-.*$
$1thumb.php?f=$2&width=$3&archived=1 [L,QSA]

# Handler for 404 pages
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^/?.*$ /index.php?title=Special:Error404
RewriteRule
^(/?)images/thumb/[0-9a-f]/[0-9a-f][0-9a-f]/([^/]+)/([0-9]+)px-.*$
$1thumb.php?f=$2&width=$3 [L,QSA]


I haven't figured out how to replicate that bug 28235 fix in Nginx though.

~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]

On 11-04-19 09:28 AM, Daniel Friesen wrote:
> Using the rewrite inside images/.htaccess appears to conflict with
> existing installations with a root .htaccess including the code for the
> thumbnail handler.
>
> You won't notice it right away because most images will already have
> existing thumbnails generated, but at some random point when someone.
>
> In fact, I ONLY found out things were broken on any of my wiki after I
> created a brand new wiki with similar config and found I got 404s
> instead of thumbnails.
>
> My fix was to comment out the code in images/.htaccess and add it to my
> root .htaccess. Of course I'll need to do something else on another one
> of my wiki that uses a separate domain for serving uploads.
>
> ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l