Heh, you think? Deploying a new browser is not a trivial exercise in some large-scale environments.
And a lot of companies have really useless IT departments (i.e. no budget). Trust me; we get employed (at vastly greater expense than simply upgrading) to tell them why their IT infrastructure is so insecure. Tom On 3 June 2011 21:35, Mono mium <[email protected]> wrote: > 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 > _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
