On Thu, Jun 2, 2011 at 5:21 PM, Tim Starling tstarling@wikimedia.orgwrote:
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