On 14/04/11 17:29, Gordon Joly wrote:

I see that this snippet is to be found in ".htaccess" file inside ./images/ (this appears to be new file 1.16.3)

Could the ".htaccess" be placed at top level (that is one above ./images/)?

If you do that, then certain URLs that give harmless HTML responses will be blacklisted. For example, if you type ".html" into the search box and hit enter, you get the URL:

http://en.wikipedia.org/w/index.php?title=Special%3ASearch&search=.html

This URL would be forbidden if you applied the .htaccess at the top level, despite it being harmless, as far as we know. However, it's a reasonable thing to do if you care more about security than about such inconveniences, and you're worried that we might be missing something.

I did apply it at the top level for *.m.wikipedia.org, because it's difficult to get things fixed in the mobile application. The result is that we have to put up with bug 28510 for now.

Since the file is there, is there any need to change the web server configuration?

No, as long as you have an appropriate AllowOverride directive in your web server configuration. To test it, go to any image on the wiki and append "?.html" to the URL. For example:

http://<wiki domain>/images/d/d9/Test.png?.html

It should show "403 Forbidden". If it shows the image, then you have to change your web server configuration.

-- Tim Starling

I got several emails too. Quite distracting.

----- Original Message ----- From: "Rick Payton" rick@mai-hawaii.com To: mediawiki-l@lists.wikimedia.org Date: Wed, 25 May 2011 11:46:33 -1000 Subject: Re: [Mediawiki-l] [MediaWiki-announce] MediaWiki security release 1.16.3

Am I the only person that's noticed Tim reposting of all the updates? Is the list server freaking out, or is my end messing with me?

Rick Payton, I.T. Manager Morikawa & Associates, LLC (808) 572-1745 Office (808) 442-0978 eFax (808) 344-8249 Mobile www.mai-hawaii.com

-----Original Message----- From: mediawiki-l-bounces@lists.wikimedia.org [mailto:mediawiki-l-bounces@lists.wikimedia.org] On Behalf Of Tim Starling Sent: Monday, April 11, 2011 5:23 PM To: mediawiki-announce@lists.wikimedia.org; mediawiki-l@lists.wikimedia.org; wikitech-l@lists.wikimedia.org Subject: [Mediawiki-l] [MediaWiki-announce] MediaWiki security release 1.16.3

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

I would like to announce the release of MediaWiki 1.16.3, which is a security release. Three security issues were discovered.

Masato Kinugawa discovered a cross-site scripting (XSS) issue, which affects Internet Explorer clients only, and only version 6 and earlier. Web server configuration changes are required to fix this issue. Upgrading MediaWiki will only be sufficient for people who use Apache with AllowOverride enabled.

Due to the diversity of uploaded files that we allow, MediaWiki does not guarantee that uploaded files will be safe if they are interpreted by the client as some arbitrary file type, such as HTML. We rely on the web server to send the correct Content-Type header, and we rely on the web browser to respect it. This XSS issue arises due to IE 6 looking for a file extension in the query string of the URL (i.e. after the "?"), if no extension is found in path part of the URL. Masato Kinugawa discovered that the file extension in the path part can be hidden from IE 6 by substituting the "." with "%2E".

To fix this issue, configure your web server to deny requests with URLs that have a path part ending in a dot followed by a dangerous file extension. For example, in Apache with mod_rewrite:

RewriteEngine On
RewriteCond %{QUERY_STRING} \.[a-z]{1,4}$ [nocase]
RewriteRule . - [forbidden]

Upgrading MediaWiki is necessary to fix this issue in dynamically-generated content. This issue is easier to exploit using dynamically generated content, since it requires no special privileges. Accounts on both public and private wikis can be compromised by clicking a malicious link in an email or website. For more details, see bug 28235.

Wikipedia user Suffusion of Yellow discovered a CSS validation error in the wikitext parser. This is an XSS issue for Internet Explorer clients, and a privacy loss issue for other clients since it allows the embedding of arbitrary remote images. For more details, see bug 28450.

MediaWiki developer Happy-Melon discovered that the transwiki import feature neglected to perform access control checks on form submission. The transwiki import feature is disabled by default. If it is enabled, it allows wiki pages to be copied from a remote wiki listed in $wgImportSources. The issue means that any user can trigger such an import to occur. For more details, see bug 28449.

The localisations were updated using content from translatewiki.net.

---

Download: http://download.wikimedia.org/mediawiki/1.16/mediawiki-1.16.3.tar.gz

Patch to previous version (1.16.2), without interface text: http://download.wikimedia.org/mediawiki/1.16/mediawiki-1.16.3.patch.gz Interface text changes: http://download.wikimedia.org/mediawiki/1.16/mediawiki-i18n-1.16.3.patch .gz

GPG signatures: http://download.wikimedia.org/mediawiki/1.16/mediawiki-1.16.3.tar.gz.sig http://download.wikimedia.org/mediawiki/1.16/mediawiki-1.16.3.patch.gz.s ig http://download.wikimedia.org/mediawiki/1.16/mediawiki-i18n-1.16.3.patch .gz.sig

Public keys: https://secure.wikimedia.org/keys.html

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEUEARECAAYFAk2jxbAACgkQgkA+Wfn4zXn38gCWISDEZuC+Ap3Z4aBfibnuNSU1 EgCfeL2lo/4XtCuoKOwah0YbuaHyf5I= =S2JZ -----END PGP SIGNATURE-----

---

MediaWiki announcements mailing list To unsubscribe, go to: https://lists.wikimedia.org/mailman/listinfo/mediawiki-announce

---

MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

---

MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

On 26/05/11 08:31, Rick Payton wrote:

Ok good it's not me then. I just checked the archives, it would appear that Tim is ... broken :P

It's not me. One of them had these headers:

Received: from smtprelay01.ispgateway.de ([80.67.31.39]:53831) by lily.knams.wikimedia.org with esmtp (Exim 4.69) (envelope-from tstarling@wikimedia.org) id 1QIHu3-0001SE-0h; Fri, 06 May 2011 10:04:55 +0000 Received: from [79.240.133.81] (helo=optacom.com) by smtprelay01.ispgateway.de with esmtpa (Exim 4.68) (envelope-from tstarling@wikimedia.org) id 1QIHu2-0004NH-DB; Fri, 06 May 2011 12:04:54 +0200 Received: from mail pickup service by optacom.com with Microsoft SMTPSVC; Fri, 6 May 2011 12:04:53 +0200 Received: by [server1.Optacom.local (Microsoft Connector for POP3 Mailboxes)] id <"{D3597636-EB0B-4059-9554-6975A2217D24}"@Optacom.local>; Thu, 5 May 2011 07:55:04 +0200

Another even had a different envelope sender:

From zimbra@mail.samara-aviagas.ru Tue May 24 17:18:29 2011

... Received: from lists.wikimedia.org (lists.wikimedia.org [91.198.174.5]) by mail.samara-aviagas.ru (Postfix) with ESMTP id C282115A31 for dolaev-ir@samara-aviagas.ru; Thu, 5 May 2011 09:54:50 +0400 (MSD) ... From: Tim Starling tstarling@wikimedia.org

They use duplicate message IDs, which I suppose is why they didn't appear in Gmane. Maybe it's a test of a new spamming strategy. I've long said that Mailman is laughably insecure and that it's only a matter of time before it's spammed to death, and that the only solution will be to evacuate to a web forum.

-- Tim Starling

Tim Starling wrote:

They use duplicate message IDs, which I suppose is why they didn't appear in Gmane. Maybe it's a test of a new spamming strategy. I've long said that Mailman is laughably insecure and that it's only a matter of time before it's spammed to death, and that the only solution will be to evacuate to a web forum.

-- Tim Starling

It could be avoided by requiring a valid PGP signature* before sending to the list. Easy for mediawiki-announce, not so much for a list like mediawiki-l, where signed mail is the exception. Maybe a spf check would be enough for non-signed mail. If spam really break into mailing lists, then finally spammers will solve that old problem by forcing signed mail on everyone.

* Not any signature, but the one given for that email at subscription, obviously.