Anyone can upgrade, Chad. It's not hard and any sane IT department should have done it six years ago.
On Fri, Jun 3, 2011 at 1:34 PM, Chad <[email protected]> wrote: > 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 > _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
