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 monomium@gmail.com 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 innocentkiller@gmail.com wrote:
We shouldn't throw annoying text/graphics at people who probably *cant* upgrade.
-Chad On Jun 3, 2011 4:27 PM, "Mono mium" monomium@gmail.com wrote:
Why not?
On Fri, Jun 3, 2011 at 1:19 PM, Huib Laurens sterkebak@gmail.com
wrote:
Thats completly not the point.
2011/6/3, Mono mium monomium@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 markwdilley@gmail.com
wrote:
<aside from main conversation>
Would it be a good community gesture to join Microsoft in trying to eradicate IE6?
or to not join them and put up a more general banner
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 <
tstarling@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
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