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@gmail.com wrote:
<aside from main conversation>
Would it be a good community gesture to join Microsoft in trying to eradicate IE6?
or to not join them and put up a more general banner
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@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@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l