Page MenuHomePhabricator

Security Review For Mailman3 / lists.wikimedia.org
Open, LowPublic

Description

Project Information

Description of the tool/project:
Mailman3 is a rich mailing list suite, with email and web interfaces. Mailman2 was notoriously insecure, but we've also found issues with Mailman3 that are concerning and could use a deeper review.

Description of how the tool will be used at WMF:

Powers lists.wikimedia.org, facilitates public and private/sensitive discussions across wide groups of Wikimedians.

Dependencies
Technologies used:

  • Exim
  • Python/uwsgi
  • MariaDB
  • Apache httpd

Key Python dependencies:

  • SQLAlchemy
  • django
  • falcon

The rest should be specified in the corresponding setup.py files (it's a longish tree).

Has this project been reviewed before?
I am not aware of a formal review, certainly has happened informally.

Working test environment
A test environment is available in Cloud VPS: https://polymorphic.lists.wmcloud.org/postorius/lists/. Using the Puppet role is generally the best way to get our setup replicated.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript
sbassett added a project: SecTeam-Processed.
sbassett moved this task from Incoming to Back Orders on the secscrum board.
sbassett added a subscriber: sbassett.

Per IRC convo, we'll try to source a vendor for this work. Dropping in our back orders as a low priority for now.

So, full disclosure, this doesn't really have a path through the Security-Team at this point. We can help provide guidance on selecting an external vendor and working with them to complete a security review. Please let us know if any of the maintainers of this project would like to explore that option.

I'd still like to get this reviewed somehow, given how much private information is passing through it.

I'd still like to get this reviewed somehow, given how much private information is passing through it.

I'd say the best approach right now might be to see if SRE has any funding available for a vendor. If yes, we can help source proposals from some of our existing vendors or help source a vendor who might be a good fit for this work.

I'd still like to get this reviewed somehow, given how much private information is passing through it.

What private info do we have flowing thru mailman? What kind of assessment did you have in mind? Seems to me like a code review is not going to happen but we might be able to provide either some risk assessment (security/privacy), threat modeling or other consultative service to help surface and address any concerns. Additionally, we are in the process of onboarding a new pen testing vendor that could potentially have some cycles available for them to look at this but it would be good to wrap our heads around a scope. Happy to grab some time for us to chat if it's helpful.

I'd still like to get this reviewed somehow, given how much private information is passing through it.

What private info do we have flowing thru mailman?

Board, legal, VTRS, functionaries/CU/oversight, ops, and quite a few other private/sensitive mailing lists. Some of these do keep archives in hyperkitty which increases the potential attack surface.

What kind of assessment did you have in mind?

A code review mostly. Just to give an idea of the issues we've had with Mailman3 so far:

There was one more issue (missing access control again) that was recently disclosed but never made it into a release and therefore didn't affect us:

A new vulnerability was reported against Hyperkitty’s git master branch branch which can expose the archives of a private Mailing List through the new Feeds API that was added to Hyperkitty recently to someone who isn't a member or logged-in.

I would have expected a code review to have caught the last 3 issues mentioned.

Also worth pointing out that some parts of Mailman3 are mostly copied out of Mailman2, and well, I think Mailman2's security track record speaks for itself.

Seems to me like a code review is not going to happen but we might be able to provide either some risk assessment (security/privacy), threat modeling or other consultative service to help surface and address any concerns. Additionally, we are in the process of onboarding a new pen testing vendor that could potentially have some cycles available for them to look at this but it would be good to wrap our heads around a scope. Happy to grab some time for us to chat if it's helpful.

Personally I am comfortable with our current deployment in that security wise it's a big step up from Mailman2, but my suspicion is that if someone does look closely they might find other issues. We will probably be fine if we just continue to follow the upstream announcement mailing list and patch as issues are disclosed. I was also hoping this would be a good opportunity for us to support an allied/friendly free software project that we've depended on for 2+ decades now. Our Mailman setup is mostly vanilla upstream (once we catch up with the latest upstream releases that is: T286217), so a review of it would be a review of upstream basically. There have been enough moments (both security and not-security) where we asking "how has no one else run into this?" which leads me to believe no one has recently done an audit or review of Mailman3.

I am not really sure if the blocker right now is funding or resourcing/people's time or something else. After T289899#7403334, I asked @wkandek to see what our options for funding in SRE are. Or maybe we can look into the funds that were set aside for supporting other free software projects. In any case, I'm also fine for this to just sit in the backlog until we can get something figured out, there's really no urgency IMO.