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(a)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(a)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(a)gmail.com> wrote:
> Why not?
>
> On Fri, Jun 3, 2011 at 1:19 PM, Huib Laurens <sterkebak(a)gmail.com>
wrote:
> Thats
completly not the point.
>
> 2011/6/3, Mono mium <monomium(a)gmail.com>om>:
>> 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(a)gmail.com>
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 <
tstarling(a)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(a)lists.wikimedia.org
>> >
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>>
>>
>> _______________________________________________
>> Wikitech-l mailing list
>> Wikitech-l(a)lists.wikimedia.org
>>
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l(a)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(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l