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