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
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
> 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
>> actively campaigning to get the remaining
users to upgrade. :) But I
protecting, so if we can find a workaround that's
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
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
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
will probably *still* be exploitable on other web
sites that they visit
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
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
can identify that it doesn't contain an
unencoded dot in the path.
It sounds like simply checking REQUEST_URI when available would eliminate
huge portion of our false positives that affect
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
mixed unescaped into JSON?
Yes, all other content types, as I said above.
Only as drive-by downloads, or as things that execute without
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
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():
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.
Wikitech-l mailing list
Wikitech-l mailing list