On Thu, Jun 2, 2011 at 5:21 PM, Tim Starling <[email protected]>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 [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
