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
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
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:
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
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)
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
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)
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:
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
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:
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
On 14.04.2011 11:46, Guillaume Paumier wrote:
Hi,
You're in luck. These days, even Microsoft agrees with you:
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
*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:
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
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
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
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@lists.wikimedia.org