We shouldn't throw annoying text/graphics at people who probably *cant* upgrade.
-Chad On Jun 3, 2011 4:27 PM, "Mono mium" <[email protected]> wrote: > Why not? > > On Fri, Jun 3, 2011 at 1:19 PM, Huib Laurens <[email protected]> wrote: >> Thats completly not the point. >> >> 2011/6/3, Mono mium <[email protected]>: >>> 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 >>> >> >> -- >> Verzonden vanaf mijn mobiele apparaat >> >> Kind regards, >> >> Huib Laurens >> WickedWay.nl >> >> Webhosting the wicked way. >> >> _______________________________________________ >> 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
