Why not? On Fri, Jun 3, 2011 at 1:19 PM, Huib Laurens <sterke...@gmail.com> wrote: > Thats completly not the point. > > 2011/6/3, Mono mium <monom...@gmail.com>: >> 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 <markwdil...@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 <tstarl...@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 >>> >> _______________________________________________ >> Wikitech-l mailing list >> Wikitech-l@lists.wikimedia.org >> https://lists.wikimedia.org/mailman/listinfo/wikitech-l >> > > -- > Verzonden vanaf mijn mobiele apparaat > > Kind regards, > > Huib Laurens > WickedWay.nl > > Webhosting the wicked way. > > _______________________________________________ > 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
