On the IE6 query string security check breakage (bug 28235)

List overview All Threads
Download

newer

older

Renaming projects

Wikimedia projects + Open Library...

Brion Vibber

2 Jun 2011 2 Jun '11

10:56 p.m.

Is there a way we can narrow down this security check so it doesn't keep breaking API requests, action=raw requests, and ResourceLoader requests, etc? Having the last param in a query string end in say ".png" or ".svg" or ".jpg" or ".ogg" is..... very frequent when dealing with uploaded files and file pages. In addition to the reported breakages with ResourceLoader, I've seen this problem break classic-style action=raw site CSS page loads (action=raw&title=MediaWiki:Filepage.css) and API requests for MwEmbed+TimedMediaHandler's video player, for the OEmbed extension I'm fiddling with, etc. The impression I get is this is: 1) only exploitable on IE 6 (which is now a small minority and getting smaller) 2) only exploitable if the path portion of the URL does not include an unencoded period (eg 'api' or 'api%2Ephp' instead of 'api.php') 3) only exploitable if raw HTML fragments can be injected into the output, eg a '<body' or other that triggers IE's HTML detection For 1) I'm honestly a bit willing to sacrifice a few IE 6 users at this point; the vendor's dropped support, shipped three major versions, and is actively campaigning to get the remaining users to upgrade. :) But I get protecting, so if we can find a workaround that's ok. For 2) ... if we can detect this it would be great as we could avoid breaking *any* api.php, index.php, or load.php requests in most real-world situations. For 3) ... formatted & XML output from the API should always be safe as, even if it triggers XML/HTML detection you can't slip in arbitrary <script> bits. JSON output seems to be the problematic vector currently, as you can manage to get arbitrary strings embedded in some places like error messages: {"warnings":{"siteinfo":{"*":"Unrecognized value for parameter 'siprop': <body onload=alert(1)>.html"}}} On the other hand if our JSON output escaped '<' and '>' characters you'd get this totally safe document: {"warnings":{"siteinfo":{"*":"Unrecognized value for parameter 'siprop': \u003Cbody onload=alert(1)\u003E.html"}}} I tested this by slipping a couple lines into ApiFormatJson: $this->printText( $prefix . str_replace( '<', '\\u003C', str_replace( '>', '\\u003E', FormatJson::encode( $this->getResultData(), $this->getIsHtml() ) ) ) . $suffix ); and can confirm that IE 6 doesn't execute the script bit. Are there any additional exploit vectors for API output other than HTML tags mixed unescaped into JSON? -- brion

Show replies by date

Roan Kattouw

2 Jun 2 Jun

11:20 p.m.

New subject: On the IE6 query string security check breakage (bug 28235)

On Thu, Jun 2, 2011 at 10:56 PM, Brion Vibber <brion(a)pobox.com> wrote:

...

Is there a way we can narrow down this security check so it doesn't keep breaking API requests, action=raw requests, and ResourceLoader requests, etc?

Tim had an idea about redirecting bad URLs to fixed ones. He ran it by me last night his time, and my guess is he'll probably implement it this morning his time. But I'll leave it up to him to elaborate on that. Your ideas to secure api.php output against HTML abuse are interesting, but I don't think the txt and dbg formats can be fixed that way. Roan Kattouw (Catrope)

Brion Vibber

11:39 p.m.

New subject: On the IE6 query string security check breakage (bug 28235)

On Thu, Jun 2, 2011 at 2:20 PM, Roan Kattouw <roan.kattouw(a)gmail.com> wrote:

...

On Thu, Jun 2, 2011 at 10:56 PM, Brion Vibber <brion(a)pobox.com> wrote:

Is there a way we can narrow down this security check so it doesn't keep breaking API requests, action=raw requests, and ResourceLoader requests, etc?

I know this has already been brought up, but that doesn't work for POST, and may not work for API clients that don't automatically follow redirects. (Which it looks like includes MediaWiki's ForeignAPIRepo since our Http class got redirection turned off by default a couple versions ago.) Your ideas to secure api.php output against HTML abuse are

...

interesting, but I don't think the txt and dbg formats can be fixed that way.

Why do we actually have these extra unparseable formats? If they're for debug readability then we can probably just make them HTML-formatted, like jsonfm/xmlfm/etc. -- brion

Roan Kattouw

11:44 p.m.

New subject: On the IE6 query string security check breakage (bug 28235)

On Thu, Jun 2, 2011 at 11:39 PM, Brion Vibber <brion(a)pobox.com> wrote:

...

I know this has already been brought up, but that doesn't work for POST, and may not work for API clients that don't automatically follow redirects.

That's exactly what Tim said. However, I don't think POST is that much of a problem. Problematic dots can only result from 'variable' pieces of data being put in your query string, and with POST you'd typically put the variable parts in the POST body. And even if you're not doing that, moving something from the query string to the POST body should be trivial.

...

Why do we actually have these extra unparseable formats? If they're for debug readability then we can probably just make them HTML-formatted, like jsonfm/xmlfm/etc.

To be honest, I don't remember. I think they can die. I'll take a look at the revision history tomorrow to check why they were introduced in the first place. Roan Kattouw (Catrope)

Brion Vibber

11:51 p.m.

New subject: On the IE6 query string security check breakage (bug 28235)

On Thu, Jun 2, 2011 at 2:44 PM, Roan Kattouw <roan.kattouw(a)gmail.com> wrote:

...

However, I don't think POST is that much of a problem. Problematic dots can only result from 'variable' pieces of data being put in your query string, and with POST you'd typically put the variable parts in the POST body. And even if you're not doing that, moving something from the query string to the POST body should be trivial.

Good point! That helps simplify things. :D

...

Why do we actually have these extra unparseable formats? If they're for

debug readability then we can probably just make them HTML-formatted,

jsonfm/xmlfm/etc.

To be honest, I don't remember. I think they can die. I'll take a look at the revision history tomorrow to check why they were introduced in the first place.

Spiff. I'd be happy to kill 'em off entirely ;) but if there's a better way that still keeps our functional output formats safe & working, that's super. -- brion

Platonides

3 Jun 3 Jun

12:11 a.m.

New subject: On the IE6 query string security check breakage (bug 28235)

Brion Vibber wrote:

...

On Thu, Jun 2, 2011 at 2:20 PM, Roan Kattouw<roan.kattouw(a)gmail.com> wrote:

On Thu, Jun 2, 2011 at 10:56 PM, Brion Vibber<brion(a)pobox.com> wrote:

Is there a way we can narrow down this security check so it doesn't keep breaking API requests, action=raw requests, and ResourceLoader requests, etc?

Luckily ForeignAPIRepo doesn't spoof IE6, so we can just redirect IE6.

MZMcBride

3:56 a.m.

New subject: On the IE6 query string security check breakage (bug 28235)

Brion Vibber wrote:

...

Your ideas to secure api.php output against HTML abuse are interesting, but I don't think the txt and dbg formats can be fixed that way.

Why do we actually have these extra unparseable formats? If they're for debug readability then we can probably just make them HTML-formatted, like jsonfm/xmlfm/etc.

You're talking about api.php?format=txt and api.php?format=dbg? I'd strongly recommend at least rudimentary log sampling on the Wikimedia cluster to check for use frequency before making any decision. People have all sorts of strange use-cases and it could be a rather nasty breaking change for some people. It'd be nice to have hard(er) data before making a decision, even if it turns out that the idea behind having these extra formats was initially misguided. MZMcBride

Tim Starling

7:46 a.m.

New subject: On the IE6 query string security check breakage (bug 28235)

On 03/06/11 07:20, Roan Kattouw wrote:

...

I committed it in r89397. It's unconventional to have WebRequest modify the output, but it doesn't seem to break any cardinal rules, and Roan thought WebRequest is a better place for it than OutputPage since the API tries to avoid using OutputPage. -- Tim Starling

Russell N. Nelson - rnnelson

2 Jun 2 Jun

11:25 p.m.

Remember Rule #1: You can't solve social problems using technical means. The social problem is that people keep using IE6. The technical means are to protect them by pandering to IE6 security lapses. The social solution is to tell people "FFS, STOP USING IE^111". For all the reasons Brion gave below, I support the idea of checking to see if the browser is IE6, and if it is, then give them a header that says "We can no longer provide you with a secure browsing experience because you are using Internet Explorer 6" followed by a dump of the raw wikitext with any angle brackets replaced by < and >. ________________________________________ From: wikitech-l-bounces(a)lists.wikimedia.org [wikitech-l-bounces(a)lists.wikimedia.org] on behalf of Brion Vibber [brion(a)pobox.com] For 1) I'm honestly a bit willing to sacrifice a few IE 6 users at this point; the vendor's dropped support, shipped three major versions, and is actively campaigning to get the remaining users to upgrade. :) But I get protecting, so if we can find a workaround that's ok.

Roan Kattouw

11:31 p.m.

New subject: On the IE6 query string security check breakage (bug 28235)

On Thu, Jun 2, 2011 at 11:25 PM, Russell N. Nelson - rnnelson <rnnelson(a)clarkson.edu> wrote:

...

Could be cool, except we have caching proxies (Squid for api.php, Varnish for load.php) between us and the IE users, and I'm not sure we can tell them to only not cache requests for IE6. Roan Kattouw (Catrope)

Russell N. Nelson - rnnelson

11:40 p.m.

New subject: On the IE6 query string security check breakage (bug 28235)

...

Varnish for load.php) between us and the IE users, and I'm not sure we can tell them to only not cache requests for IE6.

This might work: acl ffsnoie6 browser ie6 no_cache deny ffsnoie6

Chad

11:44 p.m.

New subject: On the IE6 query string security check breakage (bug 28235)

On Thu, Jun 2, 2011 at 5:25 PM, Russell N. Nelson - rnnelson <rnnelson(a)clarkson.edu> wrote:

...

I support the proposal in spirit :) But.....wouldn't work with our cache setup. Squid doesn't filter on user agent. -Chad

Mono mium

3 Jun 3 Jun

12:06 a.m.

New subject: On the IE6 query string security check breakage (bug 28235)

Look, we're moving into a new generation of web browsers. It's time to upgrade - it's easy and free. We shouldn't spend our time/resources trying to support ten-year-old technology. Even Microsoft is trying to get people to stop and it's the responsibility of any popular website to support modern technologies. Anytime I hear 'developing for IE6' I cringe. If the time developers spent on supporting IE6 went toward modern features, we'd have some really great websites. On Thu, Jun 2, 2011 at 2:25 PM, Russell N. Nelson - rnnelson < rnnelson(a)clarkson.edu> wrote:

...

Remember Rule #1: You can't solve social problems using technical means. The social problem is that people keep using IE6. The technical means are to protect them by pandering to IE6 security lapses. The social solution is to tell people "FFS, STOP USING IE^111". For all the reasons Brion gave below, I support the idea of checking to see if the browser is IE6, and if it is, then give them a header that says "We can no longer provide you with a secure browsing experience because you are using Internet Explorer 6" followed by a dump of the raw wikitext with any angle brackets replaced by < and >. ________________________________________ From: wikitech-l-bounces(a)lists.wikimedia.org [ wikitech-l-bounces(a)lists.wikimedia.org] on behalf of Brion Vibber [ brion(a)pobox.com] For 1) I'm honestly a bit willing to sacrifice a few IE 6 users at this point; the vendor's dropped support, shipped three major versions, and is actively campaigning to get the remaining users to upgrade. :) But I get protecting, so if we can find a workaround that's ok. _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Chad

12:10 a.m.

New subject: On the IE6 query string security check breakage (bug 28235)

On Thu, Jun 2, 2011 at 6:06 PM, Mono mium <monomium(a)gmail.com> wrote:

...

I remain convinced that it's worth it-- at least for security issues-- as long as a browser retains at least 1% market share. -Chad

Tim Starling

2:21 a.m.

New subject: On the IE6 query string security check breakage (bug 28235)

On 03/06/11 06:56, Brion Vibber wrote:

...

The impression I get is this is: 1) only exploitable on IE 6 (which is now a small minority and getting smaller)

IE 6 and some earlier versions of IE, at least back to 4.

...

2) only exploitable if the path portion of the URL does not include an unencoded period (eg 'api' or 'api%2Ephp' instead of 'api.php') 3) only exploitable if raw HTML fragments can be injected into the output, eg a '<body' or other that triggers IE's HTML detection

HTML is a particularly dangerous exploit vector since it leads to XSS with no user interaction, but any content type can be faked. For example, if you use a .bat extension, IE will prompt you to execute the "batch file". So there's a potential for it being used for malware distribution. That's why we're denying all file extensions, not just .html.

...

For 1) I'm honestly a bit willing to sacrifice a few IE 6 users at this point; the vendor's dropped support, shipped three major versions, and is actively campaigning to get the remaining users to upgrade. :) But I get protecting, so if we can find a workaround that's ok.

We can't really do this without sending "Vary: User-Agent", which would completely destroy our cache hit ratio. For people who use Squid with our X-Vary-Options patch, it would be possible to use a very long X-Vary-Options header to single out IE 6 requests, but not everyone has that patch. The patch we used for 1.16.5 included a User-Agent check, but I didn't realise the caching implications. It'll be removed for 1.16.6, that's one of the main reasons for doing a 1.16.6 release.

...

For 2) ... if we can detect this it would be great as we could avoid breaking *any* api.php, index.php, or load.php requests in most real-world situations.

The main issue here is that we don't a wide variety of web servers set up for testing. We know that Apache lets you detect %2E versus dot via $_SERVER['REQUEST_URI'], but we don't know if any other web servers do that. Note that checking for %2E alone is not sufficient, a lot of installations (including Wikimedia) have an alias /wiki -> /w/index.php which can be used to exploit action=raw.

...

Are there any additional exploit vectors for API output other than HTML tags mixed unescaped into JSON?

Yes, all other content types, as I said above. I think the current solution in trunk, plus the redirect idea that I've been discussing with Roan, is our best bet for now, unless someone wants to investigate $_SERVER['REQUEST_URI']. In another post:

...

If there is an actual problem with ForeignAPIRepo then we can look at server-side special cases for it. But r89248 should allow all API requests that have a dotless value in their last GET parameter, and a quick review of ForeignAPIRepo in 1.16 and trunk indicates that it always sends such requests. The current solution could theoretically break some API clients. An informative error message and a Location header will help the maintainers of the clients to update them. Since we're talking about discarded solutions for this, maybe it's worth noting that I also investigated using a Content-Disposition header. The vulnerability involves an incorrect cache filename, and it's possible to override the cache filename using a Content-Disposition "filename" parameter. The reason I gave up on it is because we already use Content-Disposition for wfStreamFile(): header( "Content-Disposition: inline;filename*=utf-8'$wgLanguageCode'" . urlencode( basename( $fname ) ) ); IE 6 doesn't understand the charset specification, so it ignores the header and goes back to detecting the extension. -- Tim Starling

Brion Vibber

7:53 p.m.

New subject: On the IE6 query string security check breakage (bug 28235)

On Thu, Jun 2, 2011 at 5:21 PM, Tim Starling <tstarling(a)wikimedia.org>wrote;wrote:

...

On 03/06/11 06:56, Brion Vibber wrote:

I'm really thinking more along the lines of: if someone's an IE 6-or-below user they have hundreds of other exploit vectors staring them in the face too, and we can't protect them against many of them -- or ANY of them if they're visiting other sites than just an up-to-date MediaWiki. The cost of this fix has been immense; several versions of the fix with varying levels of disruption on production sites, both for IE 6 users and non-IE 6 users, and several weeks of delay on the 1.17.0 release. I'd be willing to accept a few drive-by downloads for IE 6 users; it's not ideal but it's something that their antivirus tools etc will already be watching out for, that end-users already get trained to beware of, and that will probably *still* be exploitable on other web sites that they visit anyway. The main issue here is that we don't a wide variety of web servers set

...

up for testing. We know that Apache lets you detect %2E versus dot via $_SERVER['REQUEST_URI'], but we don't know if any other web servers do that. Note that checking for %2E alone is not sufficient, a lot of installations (including Wikimedia) have an alias /wiki -> /w/index.php which can be used to exploit action=raw.

Well that should be fine; as long as we can see the "/wiki?/foo.bat" then we can identify that it doesn't contain an unencoded dot in the path. It sounds like simply checking REQUEST_URI when available would eliminate a huge portion of our false positives that affect real-world situations. Apache is still the default web server in most situations for most folks, and of course runs our own production servers.

...

Are there any additional exploit vectors for API output other than HTML

tags

mixed unescaped into JSON?

Yes, all other content types, as I said above.

Only as drive-by downloads, or as things that execute without interaction?

...

I think the current solution in trunk, plus the redirect idea that I've been discussing with Roan, is our best bet for now, unless someone wants to investigate $_SERVER['REQUEST_URI'].

*nod* Checking REQUEST_URI is probably the first thing we should do when it's available.

...

Yay! That's one less thing to worry about. :D

...

Since we're talking about discarded solutions for this, maybe it's worth noting that I also investigated using a Content-Disposition header. The vulnerability involves an incorrect cache filename, and it's possible to override the cache filename using a Content-Disposition "filename" parameter. The reason I gave up on it is because we already use Content-Disposition for wfStreamFile(): header( "Content-Disposition: inline;filename*=utf-8'$wgLanguageCode'" . urlencode( basename( $fname ) ) ); IE 6 doesn't understand the charset specification, so it ignores the header and goes back to detecting the extension.

Good to know. -- brion

Mark Dilley

8:30 p.m.

New subject: IE6

...

On Thu, Jun 2, 2011 at 5:21 PM, Tim Starling <tstarling(a)wikimedia.org>wrote;wrote:

On 03/06/11 06:56, Brion Vibber wrote:

Are there any additional exploit vectors for API output other than HTML

tags

mixed unescaped into JSON?

Yes, all other content types, as I said above.

Only as drive-by downloads, or as things that execute without interaction?

I think the current solution in trunk, plus the redirect idea that I've been discussing with Roan, is our best bet for now, unless someone wants to investigate $_SERVER['REQUEST_URI'].

*nod* Checking REQUEST_URI is probably the first thing we should do when it's available.

Yay! That's one less thing to worry about. :D

Good to know. -- brion _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Mono mium

8:55 p.m.

New subject: IE6

We don't want to use Microsoft's, whatever we do, because it promotes their own borked browser IE9. On Fri, Jun 3, 2011 at 11:30 AM, Mark Dilley <markwdilley(a)gmail.com> wrote:

...

On Thu, Jun 2, 2011 at 5:21 PM, Tim Starling <tstarling(a)wikimedia.org wrote: > On 03/06/11 06:56, Brion Vibber wrote: >> For 1) I'm honestly a bit willing to sacrifice a few IE 6 users at this >> point; the vendor's dropped support, shipped three major versions, and

>> actively campaigning to get the remaining users to upgrade. :) But I

get

protecting, so if we can find a workaround that's ok.

I'm really thinking more along the lines of: if someone's an IE

6-or-below

user they have hundreds of other exploit vectors staring them in the face too, and we can't protect them against many of them -- or ANY of them if they're visiting other sites than just an up-to-date MediaWiki. The cost of this fix has been immense; several versions of the fix with varying levels of disruption on production sites, both for IE 6 users and non-IE 6 users, and several weeks of delay on the 1.17.0 release. I'd be willing to accept a few drive-by downloads for IE 6 users; it's

not

ideal but it's something that their antivirus tools etc will already be watching out for, that end-users already get trained to beware of, and

that

will probably *still* be exploitable on other web sites that they visit anyway. The main issue here is that we don't a wide variety of web servers set

Well that should be fine; as long as we can see the "/wiki?/foo.bat" then

can identify that it doesn't contain an unencoded dot in the path. It sounds like simply checking REQUEST_URI when available would eliminate

huge portion of our false positives that affect real-world situations. Apache is still the default web server in most situations for most folks, and of course runs our own production servers.

Are there any additional exploit vectors for API output other than HTML

tags

mixed unescaped into JSON?

Yes, all other content types, as I said above.

Only as drive-by downloads, or as things that execute without

interaction?

I think the current solution in trunk, plus the redirect idea that I've been discussing with Roan, is our best bet for now, unless someone wants to investigate $_SERVER['REQUEST_URI'].

*nod* Checking REQUEST_URI is probably the first thing we should do when it's available.

Yay! That's one less thing to worry about. :D

Good to know. -- brion _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

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

Mono mium

9:07 p.m.

New subject: IE6

Or we can use: <script>for(x in document.write){document.write(x);}</script> and <input type crash> to create a more accessible and user-friendly experience.

...

From http://www.crashie.com/

Mono On Fri, Jun 3, 2011 at 11:55 AM, Mono mium <monomium(a)gmail.com> wrote:

...

We don't want to use Microsoft's, whatever we do, because it promotes their own borked browser IE9. On Fri, Jun 3, 2011 at 11:30 AM, Mark Dilley <markwdilley(a)gmail.com> wrote:

On Thu, Jun 2, 2011 at 5:21 PM, Tim Starling <tstarling(a)wikimedia.org>wrote;wrote:

On 03/06/11 06:56, Brion Vibber wrote: > For 1) I'm honestly a bit willing to sacrifice a few IE 6 users at this > point; the vendor's dropped support, shipped three major versions, and is > actively campaigning to get the remaining users to upgrade. :) But I get > protecting, so if we can find a workaround that's ok. We can't really do this without sending "Vary: User-Agent", which would completely destroy our cache hit ratio. For people who use Squid with our X-Vary-Options patch, it would be possible to use a very long X-Vary-Options header to single out IE 6 requests, but not everyone has that patch.

> Are there any additional exploit vectors for API output other than HTML tags > mixed unescaped into JSON? Yes, all other content types, as I said above.

Only as drive-by downloads, or as things that execute without interaction?

I think the current solution in trunk, plus the redirect idea that I've been discussing with Roan, is our best bet for now, unless someone wants to investigate $_SERVER['REQUEST_URI'].

*nod* Checking REQUEST_URI is probably the first thing we should do when it's available.

Yay! That's one less thing to worry about. :D

Good to know. -- brion _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

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

Huib Laurens

10:19 p.m.

New subject: IE6

Thats completly not the point. 2011/6/3, Mono mium <monomium(a)gmail.com>om>:

...

We don't want to use Microsoft's, whatever we do, because it promotes their own borked browser IE9. On Fri, Jun 3, 2011 at 11:30 AM, Mark Dilley <markwdilley(a)gmail.com> wrote:

On Thu, Jun 2, 2011 at 5:21 PM, Tim Starling <tstarling(a)wikimedia.org wrote: > On 03/06/11 06:56, Brion Vibber wrote: >> For 1) I'm honestly a bit willing to sacrifice a few IE 6 users at >> this >> point; the vendor's dropped support, shipped three major versions, and

>> actively campaigning to get the remaining users to upgrade. :) But I

get

> protecting, so if we can find a workaround that's ok. We can't really do this without sending "Vary: User-Agent", which would completely destroy our cache hit ratio. For people who use Squid with our X-Vary-Options patch, it would be possible to use a very long X-Vary-Options header to single out IE 6 requests, but not everyone has that patch.

I'm really thinking more along the lines of: if someone's an IE

6-or-below

not

ideal but it's something that their antivirus tools etc will already be watching out for, that end-users already get trained to beware of, and

that

will probably *still* be exploitable on other web sites that they visit anyway. The main issue here is that we don't a wide variety of web servers set

Well that should be fine; as long as we can see the "/wiki?/foo.bat" then

can identify that it doesn't contain an unencoded dot in the path. It sounds like simply checking REQUEST_URI when available would eliminate

huge portion of our false positives that affect real-world situations. Apache is still the default web server in most situations for most folks, and of course runs our own production servers.

> Are there any additional exploit vectors for API output other than > HTML tags > mixed unescaped into JSON? Yes, all other content types, as I said above.

Only as drive-by downloads, or as things that execute without

interaction?

I think the current solution in trunk, plus the redirect idea that I've been discussing with Roan, is our best bet for now, unless someone wants to investigate $_SERVER['REQUEST_URI'].

*nod* Checking REQUEST_URI is probably the first thing we should do when it's available.

Yay! That's one less thing to worry about. :D

Good to know. -- brion _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

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

-- Verzonden vanaf mijn mobiele apparaat Kind regards, Huib Laurens WickedWay.nl Webhosting the wicked way.

Mono mium

10:27 p.m.

New subject: IE6

Why not? On Fri, Jun 3, 2011 at 1:19 PM, Huib Laurens <sterkebak(a)gmail.com> wrote:

...

Thats completly not the point. 2011/6/3, Mono mium <monomium(a)gmail.com>om>:

We don't want to use Microsoft's, whatever we do, because it promotes their own borked browser IE9. On Fri, Jun 3, 2011 at 11:30 AM, Mark Dilley <markwdilley(a)gmail.com> wrote:

On Thu, Jun 2, 2011 at 5:21 PM, Tim Starling <tstarling(a)wikimedia.org wrote: > On 03/06/11 06:56, Brion Vibber wrote: >> For 1) I'm honestly a bit willing to sacrifice a few IE 6 users at >> this >> point; the vendor's dropped support, shipped three major versions, and

>> actively campaigning to get the remaining users to upgrade. :) But I

get

>> protecting, so if we can find a workaround that's ok. > > We can't really do this without sending "Vary: User-Agent", which > would completely destroy our cache hit ratio. For people who use Squid > with our X-Vary-Options patch, it would be possible to use a very long > X-Vary-Options header to single out IE 6 requests, but not everyone > has that patch. > I'm really thinking more along the lines of: if someone's an IE

6-or-below

not

ideal but it's something that their antivirus tools etc will already be watching out for, that end-users already get trained to beware of, and

that

will probably *still* be exploitable on other web sites that they visit anyway. The main issue here is that we don't a wide variety of web servers set > up for testing. We know that Apache lets you detect %2E versus dot via > $_SERVER['REQUEST_URI'], but we don't know if any other web servers do > that. > > Note that checking for %2E alone is not sufficient, a lot of > installations (including Wikimedia) have an alias /wiki -> > /w/index.php which can be used to exploit action=raw. > Well that should be fine; as long as we can see the "/wiki?/foo.bat" then

can identify that it doesn't contain an unencoded dot in the path. It sounds like simply checking REQUEST_URI when available would eliminate

huge portion of our false positives that affect real-world situations. Apache is still the default web server in most situations for most folks, and of course runs our own production servers. > >> Are there any additional exploit vectors for API output other than >> HTML > tags >> mixed unescaped into JSON? > > Yes, all other content types, as I said above. > Only as drive-by downloads, or as things that execute without

interaction?

> I think the current solution in trunk, plus the redirect idea that > I've been discussing with Roan, is our best bet for now, unless > someone wants to investigate $_SERVER['REQUEST_URI']. > *nod* Checking REQUEST_URI is probably the first thing we should do when it's available. > If there is an actual problem with ForeignAPIRepo then we can look at > server-side special cases for it. But r89248 should allow all API > requests that have a dotless value in their last GET parameter, and a > quick review of ForeignAPIRepo in 1.16 and trunk indicates that it > always sends such requests. > Yay! That's one less thing to worry about. :D > Since we're talking about discarded solutions for this, maybe it's > worth noting that I also investigated using a Content-Disposition > header. The vulnerability involves an incorrect cache filename, and > it's possible to override the cache filename using a > Content-Disposition "filename" parameter. The reason I gave up on it > is because we already use Content-Disposition for wfStreamFile(): > > header( "Content-Disposition: > inline;filename*=utf-8'$wgLanguageCode'" . urlencode( basename( $fname > ) ) ); > > IE 6 doesn't understand the charset specification, so it ignores the > header and goes back to detecting the extension. > Good to know. -- brion _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

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

-- Verzonden vanaf mijn mobiele apparaat Kind regards, Huib Laurens WickedWay.nl Webhosting the wicked way. _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Huib Laurens

10:32 p.m.

New subject: IE6

We shouldn't focus on getting people away from IE. We should stay neutral and advice people to upgrade. 2011/6/3, Mono mium <monomium(a)gmail.com>om>:

...

Why not? On Fri, Jun 3, 2011 at 1:19 PM, Huib Laurens <sterkebak(a)gmail.com> wrote:

Thats completly not the point. 2011/6/3, Mono mium <monomium(a)gmail.com>om>:

We don't want to use Microsoft's, whatever we do, because it promotes their own borked browser IE9. On Fri, Jun 3, 2011 at 11:30 AM, Mark Dilley <markwdilley(a)gmail.com> wrote:

<aside from main conversation> Would it be a good community gesture to join Microsoft in trying to eradicate IE6? http://TheIE6Countdown.com or to not join them and put up a more general banner http://IE6NoMore.com and move on? </aside from main conversation> On 03Jun2011, at 10:53 AM, Brion Vibber wrote: > On Thu, Jun 2, 2011 at 5:21 PM, Tim Starling <tstarling(a)wikimedia.org >wrote: > >> On 03/06/11 06:56, Brion Vibber wrote: >>> For 1) I'm honestly a bit willing to sacrifice a few IE 6 users at >>> this >>> point; the vendor's dropped support, shipped three major versions, >>> and is >>> actively campaigning to get the remaining users to upgrade. :) But I get >>> protecting, so if we can find a workaround that's ok. >> >> We can't really do this without sending "Vary: User-Agent", which >> would completely destroy our cache hit ratio. For people who use >> Squid >> with our X-Vary-Options patch, it would be possible to use a very >> long >> X-Vary-Options header to single out IE 6 requests, but not everyone >> has that patch. >> > > I'm really thinking more along the lines of: if someone's an IE 6-or-below > user they have hundreds of other exploit vectors staring them in the > face > too, and we can't protect them against many of them -- or ANY of them > if > they're visiting other sites than just an up-to-date MediaWiki. > > The cost of this fix has been immense; several versions of the fix > with > varying levels of disruption on production sites, both for IE 6 users > and > non-IE 6 users, and several weeks of delay on the 1.17.0 release. > > I'd be willing to accept a few drive-by downloads for IE 6 users; it's not > ideal but it's something that their antivirus tools etc will already > be > watching out for, that end-users already get trained to beware of, and that > will probably *still* be exploitable on other web sites that they > visit > anyway. > > > The main issue here is that we don't a wide variety of web servers set >> up for testing. We know that Apache lets you detect %2E versus dot >> via >> $_SERVER['REQUEST_URI'], but we don't know if any other web servers >> do >> that. >> >> Note that checking for %2E alone is not sufficient, a lot of >> installations (including Wikimedia) have an alias /wiki -> >> /w/index.php which can be used to exploit action=raw. >> > > Well that should be fine; as long as we can see the "/wiki?/foo.bat" > then we > can identify that it doesn't contain an unencoded dot in the path. > > It sounds like simply checking REQUEST_URI when available would > eliminate a > huge portion of our false positives that affect real-world situations. > Apache is still the default web server in most situations for most > folks, > and of course runs our own production servers. > > >> >>> Are there any additional exploit vectors for API output other than >>> HTML >> tags >>> mixed unescaped into JSON? >> >> Yes, all other content types, as I said above. >> > > Only as drive-by downloads, or as things that execute without interaction? > > >> I think the current solution in trunk, plus the redirect idea that >> I've been discussing with Roan, is our best bet for now, unless >> someone wants to investigate $_SERVER['REQUEST_URI']. >> > > *nod* Checking REQUEST_URI is probably the first thing we should do > when > it's available. > > >> If there is an actual problem with ForeignAPIRepo then we can look at >> server-side special cases for it. But r89248 should allow all API >> requests that have a dotless value in their last GET parameter, and a >> quick review of ForeignAPIRepo in 1.16 and trunk indicates that it >> always sends such requests. >> > > Yay! That's one less thing to worry about. :D > > >> Since we're talking about discarded solutions for this, maybe it's >> worth noting that I also investigated using a Content-Disposition >> header. The vulnerability involves an incorrect cache filename, and >> it's possible to override the cache filename using a >> Content-Disposition "filename" parameter. The reason I gave up on it >> is because we already use Content-Disposition for wfStreamFile(): >> >> header( "Content-Disposition: >> inline;filename*=utf-8'$wgLanguageCode'" . urlencode( basename( >> $fname >> ) ) ); >> >> IE 6 doesn't understand the charset specification, so it ignores the >> header and goes back to detecting the extension. >> > > Good to know. > > -- brion > _______________________________________________ > Wikitech-l mailing list > Wikitech-l(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

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

-- Verzonden vanaf mijn mobiele apparaat Kind regards, Huib Laurens WickedWay.nl Webhosting the wicked way.

Chad

10:34 p.m.

New subject: IE6

We shouldn't throw annoying text/graphics at people who probably *cant* upgrade. -Chad On Jun 3, 2011 4:27 PM, "Mono mium" <monomium(a)gmail.com> wrote:

...

Why not? On Fri, Jun 3, 2011 at 1:19 PM, Huib Laurens <sterkebak(a)gmail.com> wrote: > Thats completly not the point. > > 2011/6/3, Mono mium <monomium(a)gmail.com>om>: >> We don't want to use Microsoft's, whatever we do, because it promotes

their

...

>> own borked browser IE9. >> >> On Fri, Jun 3, 2011 at 11:30 AM, Mark Dilley <markwdilley(a)gmail.com>

wrote:

...

>> >>> <aside from main conversation> >>> >>> Would it be a good community gesture to join Microsoft in trying to >>> eradicate IE6? >>> >>> http://TheIE6Countdown.com >>> >>> or to not join them and put up a more general banner >>> >>> http://IE6NoMore.com >>> >>> and move on? >>> >>> </aside from main conversation> >>> >>> >>> On 03Jun2011, at 10:53 AM, Brion Vibber wrote: >>> >>> > On Thu, Jun 2, 2011 at 5:21 PM, Tim Starling <tstarling(a)wikimedia.org >>> >wrote: >>> > >>> >> On 03/06/11 06:56, Brion Vibber wrote: >>> >>> For 1) I'm honestly a bit willing to sacrifice a few IE 6 users at >>> >>> this >>> >>> point; the vendor's dropped support, shipped three major versions,

and

...

>>> is >>> >>> actively campaigning to get the remaining users to upgrade. :) But

...

>>> get >>> >>> protecting, so if we can find a workaround that's ok. >>> >> >>> >> We can't really do this without sending "Vary: User-Agent", which >>> >> would completely destroy our cache hit ratio. For people who use

Squid

...

>>> >> with our X-Vary-Options patch, it would be possible to use a very

long

...

>>> >> X-Vary-Options header to single out IE 6 requests, but not everyone >>> >> has that patch. >>> >> >>> > >>> > I'm really thinking more along the lines of: if someone's an IE >>> 6-or-below >>> > user they have hundreds of other exploit vectors staring them in the >>> > face >>> > too, and we can't protect them against many of them -- or ANY of them

...

>>> > they're visiting other sites than just an up-to-date MediaWiki. >>> > >>> > The cost of this fix has been immense; several versions of the fix

with

...

>>> > varying levels of disruption on production sites, both for IE 6 users >>> > and >>> > non-IE 6 users, and several weeks of delay on the 1.17.0 release. >>> > >>> > I'd be willing to accept a few drive-by downloads for IE 6 users;

it's

...

>>> not >>> > ideal but it's something that their antivirus tools etc will already

...

>>> > watching out for, that end-users already get trained to beware of,

and

...

>>> that >>> > will probably *still* be exploitable on other web sites that they

visit

...

>>> > anyway. >>> > >>> > >>> > The main issue here is that we don't a wide variety of web servers

set

...

>>> >> up for testing. We know that Apache lets you detect %2E versus dot

via

...

>>> >> $_SERVER['REQUEST_URI'], but we don't know if any other web servers

...

>>> >> that. >>> >> >>> >> Note that checking for %2E alone is not sufficient, a lot of >>> >> installations (including Wikimedia) have an alias /wiki -> >>> >> /w/index.php which can be used to exploit action=raw. >>> >> >>> > >>> > Well that should be fine; as long as we can see the "/wiki?/foo.bat" >>> > then >>> we >>> > can identify that it doesn't contain an unencoded dot in the path. >>> > >>> > It sounds like simply checking REQUEST_URI when available would >>> > eliminate >>> a >>> > huge portion of our false positives that affect real-world

situations.

...

>>> > Apache is still the default web server in most situations for most >>> > folks, >>> > and of course runs our own production servers. >>> > >>> > >>> >> >>> >>> Are there any additional exploit vectors for API output other than >>> >>> HTML >>> >> tags >>> >>> mixed unescaped into JSON? >>> >> >>> >> Yes, all other content types, as I said above. >>> >> >>> > >>> > Only as drive-by downloads, or as things that execute without >>> interaction? >>> > >>> > >>> >> I think the current solution in trunk, plus the redirect idea that >>> >> I've been discussing with Roan, is our best bet for now, unless >>> >> someone wants to investigate $_SERVER['REQUEST_URI']. >>> >> >>> > >>> > *nod* Checking REQUEST_URI is probably the first thing we should do

when

...

>>> > it's available. >>> > >>> > >>> >> If there is an actual problem with ForeignAPIRepo then we can look

...

>>> >> server-side special cases for it. But r89248 should allow all API >>> >> requests that have a dotless value in their last GET parameter, and

...

>>> >> quick review of ForeignAPIRepo in 1.16 and trunk indicates that it >>> >> always sends such requests. >>> >> >>> > >>> > Yay! That's one less thing to worry about. :D >>> > >>> > >>> >> Since we're talking about discarded solutions for this, maybe it's >>> >> worth noting that I also investigated using a Content-Disposition >>> >> header. The vulnerability involves an incorrect cache filename, and >>> >> it's possible to override the cache filename using a >>> >> Content-Disposition "filename" parameter. The reason I gave up on it >>> >> is because we already use Content-Disposition for wfStreamFile(): >>> >> >>> >> header( "Content-Disposition: >>> >> inline;filename*=utf-8'$wgLanguageCode'" . urlencode( basename(

$fname

...

>> ) ) ); >> >> IE 6 doesn't understand the charset specification, so it ignores the >> header and goes back to detecting the extension. >> > > Good to know. > > -- brion > _______________________________________________ > Wikitech-l mailing list > Wikitech-l(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

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

Mono mium

10:35 p.m.

New subject: IE6

Anyone can upgrade, Chad. It's not hard and any sane IT department should have done it six years ago. On Fri, Jun 3, 2011 at 1:34 PM, Chad <innocentkiller(a)gmail.com> wrote:

...

We shouldn't throw annoying text/graphics at people who probably *cant* upgrade. -Chad On Jun 3, 2011 4:27 PM, "Mono mium" <monomium(a)gmail.com> wrote:

their

>> own borked browser IE9. >> >> On Fri, Jun 3, 2011 at 11:30 AM, Mark Dilley <markwdilley(a)gmail.com>

wrote:

and

>>> is >>> >>> actively campaigning to get the remaining users to upgrade. :) But

Squid

>>> >> with our X-Vary-Options patch, it would be possible to use a very

long

>>> > they're visiting other sites than just an up-to-date MediaWiki. >>> > >>> > The cost of this fix has been immense; several versions of the fix

with

it's

>>> not >>> > ideal but it's something that their antivirus tools etc will already

>>> > watching out for, that end-users already get trained to beware of,

and

>>> that >>> > will probably *still* be exploitable on other web sites that they

visit

>>> > anyway. >>> > >>> > >>> > The main issue here is that we don't a wide variety of web servers

set

>>> >> up for testing. We know that Apache lets you detect %2E versus dot

via

>>> >> $_SERVER['REQUEST_URI'], but we don't know if any other web servers

situations.

when

>>> > it's available. >>> > >>> > >>> >> If there is an actual problem with ForeignAPIRepo then we can look

>>> >> server-side special cases for it. But r89248 should allow all API >>> >> requests that have a dotless value in their last GET parameter, and

$fname

> >> ) ) ); > >> > >> IE 6 doesn't understand the charset specification, so it ignores the > >> header and goes back to detecting the extension. > >> > > > > Good to know. > > > > -- brion > > _______________________________________________ > > Wikitech-l mailing list > > Wikitech-l(a)lists.wikimedia.org > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > > > _______________________________________________ > Wikitech-l mailing list > Wikitech-l(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

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

Roan Kattouw

10:45 p.m.

New subject: IE6

On Fri, Jun 3, 2011 at 10:35 PM, Mono mium <monomium(a)gmail.com> wrote:

...

Anyone can upgrade, Chad. It's not hard and any sane IT department should have done it six years ago.

That doesn't mean we should punish people that work for a company with a less sane IT department. Roan Kattouw (Catrope)

Greenman, Ronald (NIH/CIT) [C]

10:47 p.m.

New subject: IE6

Anyone who has control of the computer they use can upgrade, but a surprising (depressing?) number of people don't have that kind of control. In particular, schools and libraries are notorious for being stuck with failbrowsers of one sort or another, and a significant number of people depend on these sorts of places for their only Internet access. I'm not sure we're yet at the stage where *most* people using IE6 don't have the ability to upgrade, but as time goes on that proportion is only going to get larger. What's the use in annoying people to try and get them to do something they can't do? You're right that any sane IT department should have upgraded years ago. Unfortunately, many IT departments are not driven by sanity, and even those that are, sometimes their bosses are not. -----Original Message----- From: Mono mium [mailto:monomium@gmail.com] Sent: Friday, June 03, 2011 4:36 PM To: Wikimedia developers Subject: Re: [Wikitech-l] IE6 Anyone can upgrade, Chad. It's not hard and any sane IT department should have done it six years ago. On Fri, Jun 3, 2011 at 1:34 PM, Chad <innocentkiller(a)gmail.com> wrote:

...

We shouldn't throw annoying text/graphics at people who probably *cant* upgrade. -Chad On Jun 3, 2011 4:27 PM, "Mono mium" <monomium(a)gmail.com> wrote:

their

>> own borked browser IE9. >> >> On Fri, Jun 3, 2011 at 11:30 AM, Mark Dilley <markwdilley(a)gmail.com>

wrote:

and

>>> is >>> >>> actively campaigning to get the remaining users to upgrade. :) But

Squid

>>> >> with our X-Vary-Options patch, it would be possible to use a very

long

>>> > they're visiting other sites than just an up-to-date MediaWiki. >>> > >>> > The cost of this fix has been immense; several versions of the fix

with

it's

>>> not >>> > ideal but it's something that their antivirus tools etc will already

>>> > watching out for, that end-users already get trained to beware of,

and

>>> that >>> > will probably *still* be exploitable on other web sites that they

visit

>>> > anyway. >>> > >>> > >>> > The main issue here is that we don't a wide variety of web servers

set

>>> >> up for testing. We know that Apache lets you detect %2E versus dot

via

>>> >> $_SERVER['REQUEST_URI'], but we don't know if any other web servers

situations.

when

>>> > it's available. >>> > >>> > >>> >> If there is an actual problem with ForeignAPIRepo then we can look

>>> >> server-side special cases for it. But r89248 should allow all API >>> >> requests that have a dotless value in their last GET parameter, and

$fname

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

Mark Dilley

10:55 p.m.

New subject: IE6

Good point Ronald, The more people who are constantly told this message - the more will put pressure on their IT departments to change. That is how lots of change happens. Pressure. I think that Wikipedia's place in the internet community as all things encyclopedic will help this change. How much time would it save WikiMedia engineers (volunteer & staff) if we did something like this instead of engineering for IE6? /me done with this line of thought, thanks for the consideration --- Mark On 03Jun2011, at 1:47 PM, Greenman, Ronald (NIH/CIT) [C] wrote:

...

We shouldn't throw annoying text/graphics at people who probably *cant* upgrade. -Chad On Jun 3, 2011 4:27 PM, "Mono mium" <monomium(a)gmail.com> wrote:

their

>> own borked browser IE9. >> >> On Fri, Jun 3, 2011 at 11:30 AM, Mark Dilley <markwdilley(a)gmail.com>

wrote:

>> >>> <aside from main conversation> >>> >>> Would it be a good community gesture to join Microsoft in trying to >>> eradicate IE6? >>> >>> http://TheIE6Countdown.com >>> >>> or to not join them and put up a more general banner >>> >>> http://IE6NoMore.com >>> >>> and move on? >>> >>> </aside from main conversation> >>> >>> >>> On 03Jun2011, at 10:53 AM, Brion Vibber wrote: >>> >>>> On Thu, Jun 2, 2011 at 5:21 PM, Tim Starling <tstarling(a)wikimedia.org >>>> wrote: >>>> >>>>> On 03/06/11 06:56, Brion Vibber wrote: >>>>>> For 1) I'm honestly a bit willing to sacrifice a few IE 6 users at >>>>>> this >>>>>> point; the vendor's dropped support, shipped three major versions,

and

>>> is >>>>>> actively campaigning to get the remaining users to upgrade. :) But

>>> get >>>>>> protecting, so if we can find a workaround that's ok. >>>>> >>>>> We can't really do this without sending "Vary: User-Agent", which >>>>> would completely destroy our cache hit ratio. For people who use

Squid

>>>>> with our X-Vary-Options patch, it would be possible to use a very

long

>>>>> X-Vary-Options header to single out IE 6 requests, but not everyone >>>>> has that patch. >>>>> >>>> >>>> I'm really thinking more along the lines of: if someone's an IE >>> 6-or-below >>>> user they have hundreds of other exploit vectors staring them in the >>>> face >>>> too, and we can't protect them against many of them -- or ANY of them

>>>> they're visiting other sites than just an up-to-date MediaWiki. >>>> >>>> The cost of this fix has been immense; several versions of the fix

with

>>>> varying levels of disruption on production sites, both for IE 6 users >>>> and >>>> non-IE 6 users, and several weeks of delay on the 1.17.0 release. >>>> >>>> I'd be willing to accept a few drive-by downloads for IE 6 users;

it's

>>> not >>>> ideal but it's something that their antivirus tools etc will already

>>>> watching out for, that end-users already get trained to beware of,

and

>>> that >>>> will probably *still* be exploitable on other web sites that they

visit

>>>> anyway. >>>> >>>> >>>> The main issue here is that we don't a wide variety of web servers

set

>>>>> up for testing. We know that Apache lets you detect %2E versus dot

via

>>>>> $_SERVER['REQUEST_URI'], but we don't know if any other web servers

>>>>> that. >>>>> >>>>> Note that checking for %2E alone is not sufficient, a lot of >>>>> installations (including Wikimedia) have an alias /wiki -> >>>>> /w/index.php which can be used to exploit action=raw. >>>>> >>>> >>>> Well that should be fine; as long as we can see the "/wiki?/foo.bat" >>>> then >>> we >>>> can identify that it doesn't contain an unencoded dot in the path. >>>> >>>> It sounds like simply checking REQUEST_URI when available would >>>> eliminate >>> a >>>> huge portion of our false positives that affect real-world

situations.

>>>> Apache is still the default web server in most situations for most >>>> folks, >>>> and of course runs our own production servers. >>>> >>>> >>>>> >>>>>> Are there any additional exploit vectors for API output other than >>>>>> HTML >>>>> tags >>>>>> mixed unescaped into JSON? >>>>> >>>>> Yes, all other content types, as I said above. >>>>> >>>> >>>> Only as drive-by downloads, or as things that execute without >>> interaction? >>>> >>>> >>>>> I think the current solution in trunk, plus the redirect idea that >>>>> I've been discussing with Roan, is our best bet for now, unless >>>>> someone wants to investigate $_SERVER['REQUEST_URI']. >>>>> >>>> >>>> *nod* Checking REQUEST_URI is probably the first thing we should do

when

>>>> it's available. >>>> >>>> >>>>> If there is an actual problem with ForeignAPIRepo then we can look

>>>>> server-side special cases for it. But r89248 should allow all API >>>>> requests that have a dotless value in their last GET parameter, and

>>>>> quick review of ForeignAPIRepo in 1.16 and trunk indicates that it >>>>> always sends such requests. >>>>> >>>> >>>> Yay! That's one less thing to worry about. :D >>>> >>>> >>>>> Since we're talking about discarded solutions for this, maybe it's >>>>> worth noting that I also investigated using a Content-Disposition >>>>> header. The vulnerability involves an incorrect cache filename, and >>>>> it's possible to override the cache filename using a >>>>> Content-Disposition "filename" parameter. The reason I gave up on it >>>>> is because we already use Content-Disposition for wfStreamFile(): >>>>> >>>>> header( "Content-Disposition: >>>>> inline;filename*=utf-8'$wgLanguageCode'" . urlencode( basename(

$fname

>>>> ) ) ); >>>> >>>> IE 6 doesn't understand the charset specification, so it ignores the >>>> header and goes back to detecting the extension. >>>> >>> >>> Good to know. >>> >>> -- brion >>> _______________________________________________ >>> Wikitech-l mailing list >>> Wikitech-l(a)lists.wikimedia.org >>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l >> >> >> _______________________________________________ >> Wikitech-l mailing list >> Wikitech-l(a)lists.wikimedia.org >> https://lists.wikimedia.org/mailman/listinfo/wikitech-l >> > _______________________________________________ > Wikitech-l mailing list > Wikitech-l(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > -- Verzonden vanaf mijn mobiele apparaat Kind regards, Huib Laurens WickedWay.nl Webhosting the wicked way. _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

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

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

Thomas Morton

10:49 p.m.

New subject: IE6

Heh, you think? Deploying a new browser is not a trivial exercise in some large-scale environments. And a lot of companies have really useless IT departments (i.e. no budget). Trust me; we get employed (at vastly greater expense than simply upgrading) to tell them why their IT infrastructure is so insecure. Tom On 3 June 2011 21:35, Mono mium <monomium(a)gmail.com> wrote:

...

Anyone can upgrade, Chad. It's not hard and any sane IT department should have done it six years ago. On Fri, Jun 3, 2011 at 1:34 PM, Chad <innocentkiller(a)gmail.com> wrote:

We shouldn't throw annoying text/graphics at people who probably *cant* upgrade. -Chad On Jun 3, 2011 4:27 PM, "Mono mium" <monomium(a)gmail.com> wrote: > Why not? > > On Fri, Jun 3, 2011 at 1:19 PM, Huib Laurens <sterkebak(a)gmail.com>

wrote:

> Thats completly not the point. > > 2011/6/3, Mono mium <monomium(a)gmail.com>om>: >> We don't want to use Microsoft's, whatever we do, because it promotes

their

>> own borked browser IE9. >> >> On Fri, Jun 3, 2011 at 11:30 AM, Mark Dilley <markwdilley(a)gmail.com>

wrote: >>> >>>> <aside from main conversation> >>>> >>>> Would it be a good community gesture to join Microsoft in trying to >>>> eradicate IE6? >>>> >>>> http://TheIE6Countdown.com >>>> >>>> or to not join them and put up a more general banner >>>> >>>> http://IE6NoMore.com >>>> >>>> and move on? >>>> >>>> </aside from main conversation> >>>> >>>> >>>> On 03Jun2011, at 10:53 AM, Brion Vibber wrote: >>>> >>>> > On Thu, Jun 2, 2011 at 5:21 PM, Tim Starling <

tstarling(a)wikimedia.org

>>>> >wrote: >>>> > >>>> >> On 03/06/11 06:56, Brion Vibber wrote: >>>> >>> For 1) I'm honestly a bit willing to sacrifice a few IE 6 users

>>>> >>> this >>>> >>> point; the vendor's dropped support, shipped three major

versions,

and >>>> is >>>> >>> actively campaigning to get the remaining users to upgrade. :)

But

Squid

>>> >> with our X-Vary-Options patch, it would be possible to use a very

long >>>> >> X-Vary-Options header to single out IE 6 requests, but not

everyone

>>>> >> has that patch. >>>> >> >>>> > >>>> > I'm really thinking more along the lines of: if someone's an IE >>>> 6-or-below >>>> > user they have hundreds of other exploit vectors staring them in

the

>>>> > face >>>> > too, and we can't protect them against many of them -- or ANY of

them

>>> > they're visiting other sites than just an up-to-date MediaWiki. >>> > >>> > The cost of this fix has been immense; several versions of the fix

with >>>> > varying levels of disruption on production sites, both for IE 6

users

>>> > and >>> > non-IE 6 users, and several weeks of delay on the 1.17.0 release. >>> > >>> > I'd be willing to accept a few drive-by downloads for IE 6 users;

it's >>>> not >>>> > ideal but it's something that their antivirus tools etc will

already

>>> > watching out for, that end-users already get trained to beware of,

and

>>> that >>> > will probably *still* be exploitable on other web sites that they

visit

>>> > anyway. >>> > >>> > >>> > The main issue here is that we don't a wide variety of web servers

set

>>> >> up for testing. We know that Apache lets you detect %2E versus dot

via >>>> >> $_SERVER['REQUEST_URI'], but we don't know if any other web

servers

do >>>> >> that. >>>> >> >>>> >> Note that checking for %2E alone is not sufficient, a lot of >>>> >> installations (including Wikimedia) have an alias /wiki -> >>>> >> /w/index.php which can be used to exploit action=raw. >>>> >> >>>> > >>>> > Well that should be fine; as long as we can see the

"/wiki?/foo.bat"

>>> > then >>> we >>> > can identify that it doesn't contain an unencoded dot in the path. >>> > >>> > It sounds like simply checking REQUEST_URI when available would >>> > eliminate >>> a >>> > huge portion of our false positives that affect real-world

situations. >>>> > Apache is still the default web server in most situations for most >>>> > folks, >>>> > and of course runs our own production servers. >>>> > >>>> > >>>> >> >>>> >>> Are there any additional exploit vectors for API output other

than

>>> >>> HTML >>> >> tags >>> >>> mixed unescaped into JSON? >>> >> >>> >> Yes, all other content types, as I said above. >>> >> >>> > >>> > Only as drive-by downloads, or as things that execute without >>> interaction? >>> > >>> > >>> >> I think the current solution in trunk, plus the redirect idea that >>> >> I've been discussing with Roan, is our best bet for now, unless >>> >> someone wants to investigate $_SERVER['REQUEST_URI']. >>> >> >>> > >>> > *nod* Checking REQUEST_URI is probably the first thing we should do

when

>>> > it's available. >>> > >>> > >>> >> If there is an actual problem with ForeignAPIRepo then we can look

at >>>> >> server-side special cases for it. But r89248 should allow all API >>>> >> requests that have a dotless value in their last GET parameter,

and

a >>>> >> quick review of ForeignAPIRepo in 1.16 and trunk indicates that it >>>> >> always sends such requests. >>>> >> >>>> > >>>> > Yay! That's one less thing to worry about. :D >>>> > >>>> > >>>> >> Since we're talking about discarded solutions for this, maybe it's >>>> >> worth noting that I also investigated using a Content-Disposition >>>> >> header. The vulnerability involves an incorrect cache filename,

and

>>>> >> it's possible to override the cache filename using a >>>> >> Content-Disposition "filename" parameter. The reason I gave up on

>>> >> is because we already use Content-Disposition for wfStreamFile(): >>> >> >>> >> header( "Content-Disposition: >>> >> inline;filename*=utf-8'$wgLanguageCode'" . urlencode( basename(

$fname >>>> >> ) ) ); >>>> >> >>>> >> IE 6 doesn't understand the charset specification, so it ignores

the

>> >> header and goes back to detecting the extension. >> >> >> > >> > Good to know. >> > >> > -- brion >> > _______________________________________________ >> > Wikitech-l mailing list >> > Wikitech-l(a)lists.wikimedia.org >> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l >> >> >> _______________________________________________ >> Wikitech-l mailing list >> Wikitech-l(a)lists.wikimedia.org >> https://lists.wikimedia.org/mailman/listinfo/wikitech-l >> > _______________________________________________ > Wikitech-l mailing list > Wikitech-l(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > -- Verzonden vanaf mijn mobiele apparaat Kind regards, Huib Laurens WickedWay.nl Webhosting the wicked way. _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

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

Tei

11:19 p.m.

New subject: IE6

"This site is best viewed with Netscape Navigator 2.0 or higher. Download Netscape Now!" http://web.archive.org/web/19961226001115/www.cae.wisc.edu/~agnew/sp/luna.h… It seems that these messages don't get the point of the web. That is to let everyone browse the web with whatever is available to then. On 3 June 2011 20:30, Mark Dilley <markwdilley(a)gmail.com> wrote:

...

-- -- ℱin del ℳensaje.

Russell N. Nelson - rnnelson

4 Jun 4 Jun

2:04 a.m.

New subject: IE6

Another possibility is for us to 1) announce that IE6 is no longer a supported browser, and 2) just stop worrying about IE6. Not take support out, but not worry about IE6. Don't test using it, don't code for it, don't pay any attention to new IE6 vulns. Just let the IE6 support die through bit-rot. If existing IE6 support code causes a problem, take it out. Over time, people who are using IE6 can decide for themselves if they want to continue using it. This method lowers our engineering cost and increases reliability. At some point in the future, ops will report that we have had no visitors using IE6 in the last few months. Then we can go on a hunt for IE6 support and actively remove it. ________________________________________ From: wikitech-l-bounces(a)lists.wikimedia.org [wikitech-l-bounces(a)lists.wikimedia.org] on behalf of Tei [oscar.vives(a)gmail.com] Sent: Friday, June 03, 2011 5:19 PM To: Wikimedia developers Subject: Re: [Wikitech-l] IE6 "This site is best viewed with Netscape Navigator 2.0 or higher. Download Netscape Now!" http://web.archive.org/web/19961226001115/www.cae.wisc.edu/~agnew/sp/luna.h… It seems that these messages don't get the point of the web. That is to let everyone browse the web with whatever is available to then. On 3 June 2011 20:30, Mark Dilley <markwdilley(a)gmail.com> wrote:

...

-- -- ℱin del ℳensaje. _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Mono mium

2:07 a.m.

New subject: IE6

I still support <input type=crash>. On Fri, Jun 3, 2011 at 5:04 PM, Russell N. Nelson - rnnelson <rnnelson(a)clarkson.edu> wrote:

...

-- -- ℱin del ℳensaje. _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Ashar Voultoiz

9:51 a.m.

New subject: IE6

On 04/06/11 02:07, Mono mium wrote:

...

I still support<input type=crash>.

On a multiple millions visitors per day website, this is unacceptable. Most users do not even know what a 'browser' is. They just look at their computer desktop and double click the 'e' icon. Plus, 'internet explorer' sounds much better than: - 'Firefox' : will it light my computer? - 'Opera' : I listen to R'n'B I do support your crash method... on your personal website. -- Ashar Voultoiz

Lewis Cawte

5 Jun 5 Jun

9:33 p.m.

New subject: IE6

On 04/06/11 08:51, Ashar Voultoiz wrote:

...

On 04/06/11 02:07, Mono mium wrote:

I still support<input type=crash>.

Most users do not even know what a 'browser' is. They just look at their computer desktop and double click the 'e' icon.

We're talking about Wikipedia right, surely we have an article that can explain this? Even if we have to point to a simplified version or something...

Neil Kandalgaonkar

4 Jun 4 Jun

2:24 a.m.

New subject: IE6

On 6/3/11 5:04 PM, Russell N. Nelson - rnnelson wrote:

...

At some point in the future, ops will report that we have had no visitors using IE6 in the last few months. Then we can go on a hunt for IE6 support and actively remove it.

This may happen but it might be sometime in 2020. We still seem to get hits from practically every browser ever made in the last 10 years. http://stats.wikimedia.org/wikimedia/squids/SquidReportClients.htm Last month we had 3.5M hits from browsers claiming to be IE 5.5, released in mid-2000. -- Neil Kandalgaonkar ) <neilk(a)wikimedia.org>

Chad

2:31 a.m.

New subject: IE6

Not until we hit less than 1% of users using it. Not a minute before. -Chad On Jun 3, 2011 8:05 PM, "Russell N. Nelson - rnnelson" < rnnelson(a)clarkson.edu> wrote:

...

Another possibility is for us to 1) announce that IE6 is no longer a

supported browser, and 2) just stop worrying about IE6. Not take support out, but not worry about IE6. Don't test using it, don't code for it, don't pay any attention to new IE6 vulns. Just let the IE6 support die through bit-rot. If existing IE6 support code causes a problem, take it out. Over time, people who are using IE6 can decide for themselves if they want to continue using it. This method lowers our engineering cost and increases reliability. At some point in the future, ops will report that we have had no visitors using IE6 in the last few months. Then we can go on a hunt for IE6 support and actively remove it.

...

________________________________________ From: wikitech-l-bounces(a)lists.wikimedia.org [

wikitech-l-bounces(a)lists.wikimedia.org] on behalf of Tei [ oscar.vives(a)gmail.com]

...

Sent: Friday, June 03, 2011 5:19 PM To: Wikimedia developers Subject: Re: [Wikitech-l] IE6 "This site is best viewed with Netscape Navigator 2.0 or higher. Download Netscape Now!"

http://web.archive.org/web/19961226001115/www.cae.wisc.edu/~agnew/sp/luna.h…

...

It seems that these messages don't get the point of the web. That is to let everyone browse the web with whatever is available to then. On 3 June 2011 20:30, Mark Dilley <markwdilley(a)gmail.com> wrote: > <aside from main conversation> > > Would it be a good community gesture to join Microsoft in trying to

eradicate IE6?

...

http://TheIE6Countdown.com or to not join them and put up a more general banner http://IE6NoMore.com and move on? </aside from main conversation>

Tim Starling

12:32 p.m.

New subject: On the IE6 query string security check breakage (bug 28235)

On 04/06/11 03:53, Brion Vibber wrote:

...

On Thu, Jun 2, 2011 at 5:21 PM, Tim Starling <tstarling(a)wikimedia.org>wrote;wrote:

You mean by checking $_SERVER["SERVER_SOFTWARE"] or something to check if it's Apache that we're running under? I suppose that could work. It's easy enough to find out if REQUEST_URI is available. What we don't know is whether REQUEST_URI is really what was sent to the server, or whether it has %2E converted to "." before PHP gets to see it.

...

Are there any additional exploit vectors for API output other than HTML

tags

mixed unescaped into JSON?

Yes, all other content types, as I said above.

Only as drive-by downloads, or as things that execute without interaction?

Presumably that depends on what plugins are registered. I think it's better to avoid taking risks like this unless there is some good reason for doing so. With a REQUEST_URI check in place, in addition to all the other mitigating measures we now have in place, overblocking should be vanishingly rare. -- Tim Starling

Tim Starling

6 Jun 6 Jun

8:05 a.m.

New subject: On the IE6 query string security check breakage (bug 28235)

I wrote:

...

It's easy enough to find out if REQUEST_URI is available. What we don't know is whether REQUEST_URI is really what was sent to the server, or whether it has %2E converted to "." before PHP gets to see it.

I installed IIS on my Windows VM and checked this. I installed PHP from the MSI installer, which uses FastCGI by default. REQUEST_URI is indeed mangled on IIS. There's no way to tell if %2E was sent by the browser. -- Tim Starling

4707

days inactive

4711

days old

wikitech-l@lists.wikimedia.org

Manage subscription

36 comments

16 participants

tags (0)

participants (16)

Ashar Voultoiz
Brion Vibber
Chad
Greenman, Ronald (NIH/CIT) [C]
Huib Laurens
Lewis Cawte
Mark Dilley
Mono mium
MZMcBride
Neil Kandalgaonkar
Platonides
Roan Kattouw
Russell N. Nelson - rnnelson
Tei
Thomas Morton
Tim Starling