Bug 19287 - mailman new security issue CVE-2016-6893
Summary: mailman new security issue CVE-2016-6893
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: Security (show other bugs)
Version: 5
Hardware: All Linux
Priority: Normal normal
Target Milestone: ---
Assignee: QA Team
QA Contact: Sec team
URL: http://lwn.net/Vulnerabilities/699163/
Whiteboard: has_procedure MGA5-64-OK advisory
Keywords: validated_update
Depends on:
Blocks:
 
Reported: 2016-09-02 17:30 CEST by David Walser
Modified: 2016-10-18 20:44 CEST (History)
5 users (show)

See Also:
Source RPM: mailman-2.1.20-4.mga6.src.rpm
CVE:
Status comment:


Attachments

Description David Walser 2016-09-02 17:30:53 CEST
Debian-LTS has issued an advisory today (September 2):
http://lwn.net/Alerts/699147/

The issue is fixed upstream in 2.1.23:
https://mail.python.org/pipermail/mailman-announce/2016-August/000226.html

A patch is attached to this bug:
https://bugs.launchpad.net/mailman/+bug/1614841

Mageia 5 is also affected.
David Walser 2016-09-02 17:31:07 CEST

Whiteboard: (none) => MGA5TOO

Comment 1 Marja Van Waes 2016-09-06 21:10:23 CEST

Assigning to all packagers collectively, since there is no registered maintainer for this package

Assignee: bugsquad => pkg-bugs
CC: (none) => marja11

Comment 2 Mike Rambo 2016-09-16 19:22:59 CEST
Changed version from cauldron to 5 as this applies to both.

mailman-2.1.23-1.mga6 has been uploaded for cauldron/6.

Version: Cauldron => 5
CC: (none) => mrambo
Whiteboard: MGA5TOO => (none)

Comment 3 Mike Rambo 2016-09-20 16:38:32 CEST
Patched package uploaded for Mageia 5.

Advisory:
========================

Updated mailman package fixes security vulnerability:

Cross-site request forgery (CSRF) vulnerability in the user options page in 
GNU Mailman 2.1.x before 2.1.23 allows remote attackers to hijack the 
authentication of arbitrary users for requests that modify an option, as 
demonstrated by gaining access to the credentials of a victim's account 
(CVE-2016-6893).


References:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-6893
https://www.debian.org/security/2016/dsa-3668
========================

Updated packages in core/updates_testing:

mailman-2.1.20-3.mga5

from mailman-2.1.20-3.mga5.src.rpm
Mike Rambo 2016-09-20 16:39:30 CEST

Assignee: pkg-bugs => qa-bugs

Comment 4 Mike Rambo 2016-09-20 17:31:48 CEST
Potential testing procedure at:

https://bugs.mageia.org/show_bug.cgi?id=8067

Whiteboard: (none) => has_procedure

Comment 5 Lewis Smith 2016-09-25 11:14:11 CEST
(In reply to Mike Rambo from comment #4)
> Potential testing procedure at:
> https://bugs.mageia.org/show_bug.cgi?id=8067
Specifically, https://bugs.mageia.org/show_bug.cgi?id=8067#c24

CC: (none) => lewyssmith

Comment 6 Mike Rambo 2016-09-29 22:17:33 CEST
This may help in testing. It "Works For Me".

Mailman requires: httpd (or other web server)

Make sure you have something set for fqdn. For this purpose it is sufficient to just add a /etc/hosts entry.

your.box.ip.address    mmtest.example.com mmtest

Reboot to take effect.

urpmi mailman

Check the configuration in mm_cfg.py.

[choose your editor] /usr/lib64/mailman/Mailman/mm_cfg.py

You should see whatever you set for fqdn represented on the lines:

DEFAULT_EMAIL_HOST = 'example.com'
DEFAULT_URL_HOST = 'mmtest'

If you install mailman before setting fqdn these will need to be adjusted manually.

Restart the web server to pick up config changes from the mailman install.

systemctl restart httpd

From cli on the box running mailman: 

newlist testlist (and answer the questions - will create a test list)

Browse to http://localhost/mailman (or from another machine http://your.box.ip.address/mailman).

You should see the mailman front page. But unless DNS is properly set up and you are addressing the host by correct dns name you probably won't see any lists. However the testlist should be there.

Click the 'list admin overview page' hyperlink. On the browser url bar append /testlist to whatever is there and press enter. You should be asked for the list's admin password (which is whatever you provided above). On that page give it a terse phrase identifying the list in the fourth field. Update at the bottom and logout.

A hack to bypass the dns requirement to see the list is to edit /usr/lib64/mailman/Mailman/mm_cfg.py again.

Add to the bottom of the file.

VIRTUAL_HOST_OVERVIEW = Off

If you then click the 'Overview of all [example.com] mailing lists' hyperlink you should see your list.

This does not test actual mailing features but should be sufficient to establish basic function.
Comment 7 Len Lawrence 2016-10-03 19:36:03 CEST
64-bit real hardware

Tried out Mike's works-for-me instructions and they worked for me.

$ newlist testlist
newlist: Command not found.
$ sudo newlist testlist
Enter the email of the person running the list: tarazed25@gmail.com
Initial testlist password:<whatever> 
Hit enter to notify testlist owner...

$

Modified some of the entries in testlist after creating a password and logging in.
The list edits were preserved over logout/login.
Had a go at subscribing from another machine on the LAN - not sure how that went.  The application said it would be in touch.

Left the files in place and installed the update.  Is that OK?
Restarted httpd.
Browser address = localhost/mailman -> localhost/mailman/admin.cgi/testlist/general
Edited the introductory description field and logged out and in again.  The changes were preserved.
Moved to another machine and accessed testlist via the <remote host>/mailman address.

CC: (none) => tarazed25

Comment 8 Lewis Smith 2016-10-03 21:34:11 CEST
Trying Mageia 5 x64

Many thanks to Mike for his Comment 6 guidance.

Added entries as suggested to my only /etc/hosts entry:
$ cat /etc/hosts
127.0.0.1           localhost.localdomain localhost mmtest.example.com mmtest

but wonder whether mailList advice along the lines of:
127.0.0.2           mail.home.test mail
would have been more appropriate. See later.

Re-booted.
 # urpmi mailman
mailman-2.1.20-2.mga5
python-GnuPG-Interface-0.3.2-17.mga5

Create a new, unpopulated mailing list.
Usage: /usr/sbin/, lots of explanatory output.ewlist [options] [listname [listadmin-addr [admin-password]]]
Options: etc etc, lots of explanatory output.
....................
No such list "mailman"

warning: %post(mailman-2.1.20-2.mga5.x86_64) scriptlet failed, exit status 1
ERROR: 'script' failed for mailman-2.1.20-2.mga5

???

 # tail -6 /usr/lib64/mailman/Mailman/mm_cfg.py
##################################################
# Put YOUR site-specific settings below this line.
DEFAULT_EMAIL_HOST = 'localdomain'
DEFAULT_URL_HOST = 'localhost.localdomain'
add_virtualhost(DEFAULT_URL_HOST, DEFAULT_EMAIL_HOST)
MTA = 'Postfix'

I will try two /etc/hosts lines, remove mailman, and re-start from scratch.
Comment 9 Lewis Smith 2016-10-03 21:50:05 CEST
Trying Mageia 5 x64 real H/W continued.

$ cat /etc/hosts
127.0.0.1           localhost.localdomain localhost
127.0.0.2           mmtest.example.com mmtest

# urpmi mailman
    $MIRRORLIST: media/core/release/mailman-2.1.20-2.mga5.x86_64.rpm
...
Exactly the same result as before, error & mm_cfg.py included.

Will re-try with just 127.0.0.1 mmtest.example.com mmtest.
Comment 10 Lewis Smith 2016-10-03 22:46:39 CEST
Trying Mageia 5 x64 real H/W continued.

Took out mailman then /etc/mailman.rpmsave, edited /etc/hosts as below, re-boot.
 $ cat /etc/hosts
 127.0.0.1           mmtest.example.com mmtest

 # urpmi mailman
gave exactly the same O/P as previously, error & mm_cfg.py included:
 # tail -4 /usr/lib64/mailman/Mailman/mm_cfg.py
DEFAULT_EMAIL_HOST = 'localdomain'                  [?]
DEFAULT_URL_HOST = 'localhost.localdomain'          [?]
add_virtualhost(DEFAULT_URL_HOST, DEFAULT_EMAIL_HOST)
MTA = 'Postfix'

Hmm. Gave up, edited that to:
DEFAULT_EMAIL_HOST = 'example.com'
DEFAULT_URL_HOST = 'mmtest'

 # systemctl restart httpd

 # newlist testlist
and answered the couple of questions:
- an admin e-mail address
- testlist password.

Browse to http://127.0.0.1/mailman and got the 1st Welcome screen:
"127.0.0.1 Mailing Lists
Welcome!
There currently are no publicly-advertised Mailman mailing lists on 127.0.0.1. To visit the general information page for an unadvertised list, open a URL similar to this one, but with a '/' and the list name appended.
List administrators, you can visit the list admin overview page
[http://127.0.0.1/mailman/admin.cgi]
to find the management interface for your list."

Click the 'list admin overview page' hyperlink -> 2nd welcome page:
"127.0.0.1 mailing lists - Admin Links
Welcome!" etc as above.

Append '/testlist' to whatever is in the browser URL bar and press enter, displays the "Testlist Administrator Authentication" screen with the list password field. Enter that, click 'Let me in' shows the "Testlist mailing list administration
General Options Section" page, lots of potential entry fields.

In the fourth field give it a terse phrase identifying the list. Update at the bottom; and logout (top).

A hack to bypass the dns requirement to see the list:
Edit /usr/lib64/mailman/Mailman/mm_cfg.py again; add to the bottom of the file:
VIRTUAL_HOST_OVERVIEW = Off

 # tail -5 /usr/lib64/mailman/Mailman/mm_cfg.py
DEFAULT_EMAIL_HOST = 'example.com'
DEFAULT_URL_HOST = 'mmtest'
add_virtualhost(DEFAULT_URL_HOST, DEFAULT_EMAIL_HOST)
MTA = 'Postfix'
VIRTUAL_HOST_OVERVIEW = Off

Going to just http://127.0.0.1/mailman/ shows a revised 1st Welcome screen:
"mmtest Mailing Lists"
with Testlist directly shown; which shows its entry "Testlist -- mailman testlist" page.

So far so good (except for /etc/hosts dilemma). Will try the update tomorrow.
Comment 11 Mike Rambo 2016-10-04 17:15:30 CEST
Please note that https://bugs.mageia.org/show_bug.cgi?id=19386 is relevant to the post install scriptlet error.
Comment 12 Lewis Smith 2016-10-04 22:45:54 CEST
(In reply to Mike Rambo from comment #11)
> Please note that https://bugs.mageia.org/show_bug.cgi?id=19386 is relevant
> to the post install scriptlet error.
Thanks for pointing this out.

AFTER the update: mailman-2.1.20-3.mga5
This passed without incident. Restarted httpd. The Mailman system seemed to behave just the same as previously.
I tried removing the last "VIRTUAL_HOST_OVERVIEW = Off" line in
 /usr/lib64/mailman/Mailman/mm_cfg.py
and re-started httpd, but it seemed to need a reboot to see the effect: testlist no longer shown on Welcome screens, have to append it to the
 http://localhost/mailman/admin.cgi/
as originally to get its login screen.

To simplify things for the future, I tried re-setting:
 # cat /etc/hosts
 127.0.0.1           localhost.localdomain localhost
 # hostname
 localhost.localdomain             [never altered because "it is sufficient to just add a /etc/hosts entry"].
and the config file to its install defaults:
 DEFAULT_EMAIL_HOST = 'localdomain'
 DEFAULT_URL_HOST = 'localhost.localdomain'
...
and re-booted, and the web interface works fine from http://localhost/mailman/
Did I ever need to change the hosts file?
----------------------------------------
We have not looked at the server... It is in the list of services to start at boot, but not shown running. Trying to start it does not work.
# systemctl status mailman.service
â mailman.service - GNU Mailing List Manager
   Loaded: loaded (/usr/lib/systemd/system/mailman.service; enabled)
   Active: failed (Result: exit-code) since Maw 2016-10-04 22:22:04 CEST; 16min ago
  Process: 1689 ExecStart=/usr/lib64/mailman/bin/mailmanctl -s start (code=exited, status=1/FAILURE)
  Process: 1679 ExecStartPre=/bin/chmod 660 /var/log/mailman/error (code=exited, status=0/SUCCESS)
  Process: 1664 ExecStartPre=/bin/chown mail:mail /var/log/mailman/error (code=exited, status=0/SUCCESS)
  Process: 1658 ExecStartPre=/bin/touch /var/log/mailman/error (code=exited, status=0/SUCCESS)
  Process: 1619 ExecStartPre=/usr/bin/install -m644 -o root -g root /usr/lib64/mailman/cron/crontab.in /etc/cron.d/mailman (code=exited, status=0/SUCCESS)
Hyd 04 22:22:04 localhost.localdomain mailmanctl[1689]: Site list is missing:...
Hyd 04 22:22:04 localhost.localdomain systemd[1]: mailman.service: control pr...
Hyd 04 22:22:04 localhost.localdomain systemd[1]: Failed to start GNU Mailing...
Hyd 04 22:22:04 localhost.localdomain systemd[1]: Unit mailman.service entere...
Hyd 04 22:22:04 localhost.localdomain systemd[1]: mailman.service failed.
--------------------------
Does this matter? Can we OK this update just on the basis of the functional web interface?
Comment 13 Mike Rambo 2016-10-11 22:34:44 CEST
(In reply to Lewis Smith from comment #12)
> ----------------------------------------
>
> Hyd 04 22:22:04 localhost.localdomain mailmanctl[1689]: Site list is
> missing:...
>
>
> Hyd 04 22:22:04 localhost.localdomain systemd[1]: mailman.service failed.
> --------------------------
> Does this matter? Can we OK this update just on the basis of the functional
> web interface?

Not sure about the answer to your last question but it looks like the service problem is due to the post install scriptlet error. Among the things that scriptlet does is to create the site list mentioned above. Without that site list, the mailman service does not start (this is documented in mailman docs).

It would be interesting to find out whether the service would start if you manually did a "newlist mailman" to add the site list ('mailman' is hard coded to be the site list name).

I don't have a good handle on what will and will not work without the fqdn set up but it is pretty certain some things will be broken without it. Claire's original test procedure mentioned having it. Earlier today I set up a box with a full fqdn including support from an internal dns server and /etc/hosts file. When I installed mailman in that environment there was no post install scriptlet error and everything has worked.

But regarding that last question, unless you go to the lengths of setting up postfix (or sendmail) to handle the mailing you will never be able to test *all* of the mailman functions. I am new enough that I don't know how Mageia handles QA for such a circumstance. There is more than one part of that post installation scriptlet that does not work. The aliases part of it did not work in the test environment I used today and it didn't even generate an error. The aliases simply were not added. Hope this helps.
Comment 14 Lewis Smith 2016-10-13 20:32:41 CEST
Finishing M5-64
Mike: thanks for your Comment 13 elaboration.
Following the Comment 6 procedure, with the Mailman update already installed, I edited the two relevant files with what I think is my real IP address:

/etc/hosts      [but *not* /etc/host]
127.0.0.1       localhost.localdomain localhost
88.127.87.5	mmtest.example.com mmtest

/usr/lib64/mailman/Mailman/mm_cfg.py
DEFAULT_EMAIL_HOST = 'example.com'
DEFAULT_URL_HOST = 'mmtest'

Re-booted. Mailman still worked from a browser, but
 # systemctl status mailman.service
still showed failure as per Comment 12. So tried as suggested in Comment 13;

 # newlist mailman
 # systemctl restart httpd           [Just in case it matters]
 # systemctl restart mailman.service [Necessary; without this, it still failed]
 # systemctl status mailman.service
    Bingo!
â mailman.service - GNU Mailing List Manager
   Loaded: loaded (/usr/lib/systemd/system/mailman.service; enabled)
   Active: active (running) since Iau 2016-10-13 20:23:53 CEST; 6s ago
...
Hyd 13 20:23:53 localhost.localdomain mailmanctl[11117]: Starting Mailman's m...

So in line with Len's findings, am OKing this update at last.

Whiteboard: has_procedure => has_procedure MGA5-64-OK

Comment 15 Len Lawrence 2016-10-16 03:45:31 CEST
Revisiting this bug to make sure I can retrace my steps.  Started with a clean sheet on a 64bit vbox.

Tried the localhost/mailman web interface and could not create a mail list - the message indicated that I was not authorized to create lists - unsure what password was required - tried a couple or three possibilities - all failed.

Finally went back to the cli and used
$ newlist alkaid

and was then able to locate the list on the administrator page and modify it.

Starting the mailman service failed, as it did for Lewis.

Shall try the 'newlist mailman' command after updating.
Comment 16 Lewis Smith 2016-10-16 21:00:25 CEST
Am validating this update with just one OK because we are hard pressed.
Apparently the advisory (when I tried to create it) was already in place, though not marked thus in the bug; which I have done.

Keywords: (none) => validated_update
Whiteboard: has_procedure MGA5-64-OK => has_procedure MGA5-64-OK advisory
CC: (none) => sysadmin-bugs

Comment 17 Mageia Robot 2016-10-18 20:44:26 CEST
An update for this issue has been pushed to the Mageia Updates repository.

http://advisories.mageia.org/MGASA-2016-0343.html

Status: NEW => RESOLVED
Resolution: (none) => FIXED


Note You need to log in before you can comment on or make changes to this bug.