<aside from main conversation>
Would it be a good community gesture to join Microsoft in trying to eradicate IE6?
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;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