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 <[email protected]> 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 <[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 > > > _______________________________________________ > Wikitech-l mailing list > [email protected] > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
