Last modified: 2014-10-30 13:18:05 UTC
http://lists.wikimedia.org/pipermail/newprojects/2013-May/000074.html http://lists.wikimedia.org/pipermail/newprojects/2013-May/000075.html http://lists.wikimedia.org/pipermail/newprojects/2013-May/000076.html
*** Bug 48797 has been marked as a duplicate of this bug. ***
(In reply to comment #1) > *** Bug 48797 has been marked as a duplicate of this bug. *** Bah, it wasn't a dupe when I wrote it; I should have pressed save earlier. :-(
The addwiki.php script craft a delayed cron job that calls the notifyNewProjects shell script 15 minutes after the project got created. The shell is in operations/puppet.git : files/misc/scripts/notifyNewProjects and has newprojects@lists.wikimedia.org hardcoded in. Maybe it can be made yet another wg configuration variable which we could set to a different value on beta.
The code running on labs is irrelevant - it should simply be impossible for any computer outside the production cluster to successfully send a message to that list.
http://lists.wikimedia.org/pipermail/newprojects/2013-July/000079.html
I agree with Alex. A few considerations: * Lists should require smtp authentication from @wikimedia.org domains and reject the fake mail from labs (and if not already, fix the one in production to use smtp instead of sendmail). Afaik this was already talked about a while ago for other reasons, surprised it hasn't happened yet. * Members only list (like -announce, if not already), labs would be able to send as its e-mailaddress wouldn't be a valid member (I assume Mailman doesn't allow sending to a member-post-only list by simply faking the From: header to that of a member). * Some other means that makes it impossible for a simple bash script running outside production to spam this list.
What should be done is to configure this mailing list to discard mail from "non-members", that would be something to contact the list admins about: Newprojects list run by listadmin at caseybrown.org, listadmin at alexzariv.com quote " The GUI setting should be here: /admin//?VARHELP=privacy/sender/generic_nonmember_action More generally: /admin//privacy/sender "
It already does that, Daniel. It doesn't accept messages from anyone other than wiki@wikimedia.org. The issue is that the same script and address are used for labs project creations and regular wiki creations.
Well something is going wrong if a labs script can pretend to be a valid @wikimedia.org address
(In reply to comment #9) > Well something is going wrong if a labs script can pretend to be a valid > @wikimedia.org address Anyone can pretend have any email address they want. The problem is the script creating the email and mailman. Mailman would have to look at SPF records or IP addresses to see if the mail was valid and, to my knowledge, that isn't something Mailman is built to do.
Depending on what box the email is being sent from it may even match SPF ... since I know some of our boxes are on the SPF records. Most of the options described in this ticket would actually break the whole list (it wouldn't get New Wiki emails from either the cluster OR labs). If we can find a good way to fix this just in mailman 'great' (though I haven't seen an obvious way yet to do so from my brief poking around). It seems the most likely angle of attack will be the script.
(In reply to comment #11) > Depending on what box the email is being sent from it may even match SPF ... > since I know some of our boxes are on the SPF records. > > Most of the options described in this ticket would actually break the whole > list (it wouldn't get New Wiki emails from either the cluster OR labs). If we > can find a good way to fix this just in mailman 'great' (though I haven't > seen > an obvious way yet to do so from my brief poking around). It seems the most > likely angle of attack will be the script. This. ^ I don't think there's really anything we can do from the mailman angle to fix this. The script's really the only way to change this. That being said though -- are we sure it's really a problem that labs project creations get sent to the list? How often does that happen / will it happen? If it's something that happens infrequently, it probably doesn't matter if the list gets notifications.
As I said in comment #3, it is just about adapting the notifyNewProjects to have it using a different email. We could even make it exist whenever the detected realm is not production :-]
Coren: Could you take a look at this (or reset assignee to default, if not)? Thanks in advance!
*bump*. Just got another half dozen e-mails through newprojects-l about beta.wmflabs.org projects (zhwiki, ukwiki, ruwiki, kowiki, jawiki, hiwiki) that somehow made it using production credentials to this list.
(In reply to Casey Brown from comment #12) > (In reply to comment #11) > > Depending on what box the email is being sent from it may even match SPF ... > > since I know some of our boxes are on the SPF records. > > > > Most of the options described in this ticket would actually break the whole > > list (it wouldn't get New Wiki emails from either the cluster OR labs). If we > > can find a good way to fix this just in mailman 'great' (though I haven't > > seen > > an obvious way yet to do so from my brief poking around). It seems the most > > likely angle of attack will be the script. > > This. ^ > > I don't think there's really anything we can do from the mailman angle to > fix this. The script's really the only way to change this. That being said > though -- are we sure it's really a problem that labs project creations get > sent to the list? How often does that happen / will it happen? If it's > something that happens infrequently, it probably doesn't matter if the list > gets notifications. However then what's keeping any old tool labs project from creating wikis within their project (e.g. not "<enwiki>.beta.wmflabs.org", but "whatever.wmflabs.org/<wiki-[001-999]>") and for fun also spam this list? I'm pretty sure something somewhere already ensures that you can't just imitate someone @wikimedia.org from outside production (e.g. my home computer) and successfully post to a members-only list like mediawiki-announce. So why is beta able to imitate wiki@wikimedia.org and end up on newprojects-l? This looks like a security problem.
It didn't make it to the list using production credentials; posting to the list doesn't /require/ credentials. This really can only be fixed on the script side as hashar said in cmt 3 and 13. (Boldly assigning to him since there's nothing I can do on my side).
@Krinkle: Nothing; email is not secure and there is no sender verification. Anyone can fake From: headers. > I'm pretty sure something somewhere already ensures that you can't just > imitate someone @wikimedia.org from outside production (e.g. my home > computer) and successfully post to a members-only list like mediawiki-announce. Only insofar, apparently, as it doesn't come from outside our network. (I've tested it and, at the very least, naive rewriting of the From: header is filtered).
(In reply to Marc A. Pelletier from comment #19) > @Krinkle: Nothing; email is not secure and there is no sender verification. > Anyone can fake From: headers. > > > I'm pretty sure something somewhere already ensures that you can't just > > imitate someone @wikimedia.org from outside production (e.g. my home > > computer) and successfully post to a members-only list like mediawiki-announce. > > Only insofar, apparently, as it doesn't come from outside our network. > > (I've tested it and, at the very least, naive rewriting of the From: header > is filtered). But we bypass that filtering when the mail is sent from labs to production?
By design, our relays... relay mail from our network. This is a bug in the script (that it behaves like production without tweak). Yes, the possibility of abuse is there -- if someone abuse, we will advise. Someone spamming our list is a social problem, not a technical one.
After a trivial test from my home: http://lists.wikimedia.org/pipermail/newprojects/2014-April/000091.html Labs doesn't factor into it at all; any "security" provided by checking email addresses on a mailing list is futile. The only way you could actually *prevent* someone from mailing to a list from unauthenticated sources would be to... authenticate the source which neither SMTP nor mailman does.
I described the fix in comment #3 of this bug: --------------- The addwiki.php script craft a delayed cron job that calls the notifyNewProjects shell script 15 minutes after the project got created. The shell is in operations/puppet.git : files/misc/scripts/notifyNewProjects and has newprojects@lists.wikimedia.org hardcoded in. Maybe it can be made yet another wg configuration variable which we could set to a different value on beta. ------ That script need to be adjusted to either: - have the email set in puppet and vary by $::realm - get the destination email via a $wg global variable which is varying in operations/mediawiki-config.git Resetting assignee. There is nothing terribly challenging there and just anyone can fix it.
Change 168702 had a related patch set uploaded by John F. Lewis: Remove hardcoding from notifyNewProjects https://gerrit.wikimedia.org/r/168702
It's now possible to specify a location for the emails to go by changing '$wmgAddWikiNotify' to point to an email address. I discussed with Greg about dual rolling the new betacluster-alerts list for the sparse new wikis.
I don't think we need to send any announcement for the creation of wikis on the beta cluster, but if we ever want to that is now possible. Thank you John.
