SOLVED [CPANEL-29432] Mailman Bug using SSL

[brianc]

I have a verifiable bug on one of my cPanel servers that affects mailman lists when they are accessed via SSL.

I have an account that has two lists, council and members. This account has the force https switch enabled via cPanel -- Domain. The problem is on the members management page the form command is hard-coded and is being sent over a non-SSL connection:


<FORM action="http://list.domain.com/mailman/admin/members_list.domain.com/members?letter=a" method="POST" enctype="multipart/form-data">


This is preventing any changes on the membership management page from taking effect including unsubscribing a list member.

This is not happening on the council list. This list was setup later on the cPanel server but it is on the same cPanel account. The form action is being transmitted correctly over SSL:


<FORM action="../../admin/council_list.domain.com/members" method="POST" enctype="multipart/form-data">


The first question I have is did something change with a cPanel update that impacted the calling of form actions for Mailman lists after Dec/2018? The members list was setup in Dec/2018 and the council list was setup in Jan/2019.

The second question I have is how do I fix this?

Thank you for your assistance.
Brian Carpenter

 

[cPanelLauren]

Hi @brianc

I remember this thread you had open for the same issue: SSL for Mailman Admin/User Logins

There have been a number of minor version updates to Mailman 2.1.x. There was a case resolved back in May of 2018 that addressed the mailman URL itself not using https. I also found an inquiry filed by one of our analysts in 2016 which noted that some mailman URL's don't follow the DEFAULT_URL_PATTERN as defined by mailman - namely the membership management page - specifically the legend on this page. As it turns out this was an upstream issue and can be seen here: Bug #1279980 “Some forms in list admin interfaces use absolute l...” : Bugs : GNU Mailman

With that being said I'm curious if the following might be helpful: DOC/4.27 Securing Mailman's web GUI by using Secure HTTP-SSL (HTTPS) - Mailman Wiki

I'm also curious if running something like the following may fix this:

/usr/local/cpanel/3rdparty/mailman/bin/withlist -l -r fix_url listname -u list_web_domain

or for all the lists:

/usr/local/cpanel/3rdparty/mailman/bin/withlist -l -a -r fix_url

 

[brianc]

Running the fix url script fixes the issue of the ability to use the member management page but it doesn't explain why one list uses an absolute URL (the older list still does) and newer lists uses relative URLs. I only see this issue on the membership management page for the form action.

On a side note, when are you all going to update Mailman 2 to 2.1.29? This is the latest version of Mailman 2 and it was released over a year ago. This is the longest time I have seen cPanel not update Mailman. This is a cause of concern for my company.

 

[cPanelLauren]

I don't know why your specific list continued to experience the issue, part of the reason why I originally requested you open a ticket. My assumption is that the older list was there prior to the upstream bug I noted being resolved more than likely through an update pushed for mailman which (if that was the case) most likely wouldn't have included a fix for existing lists.

We updated mailman 2.1.27 at the end of March but so far I don't see any plans for 2.1.29 - if you're concerned about CVE-2018-13796 the update in March did patch this per the internal case CPANEL-26503

I've also opened CPANEL-29432 to find out what the plans are to move to 2.1.29 and I'll update here when I hear back.

 

[cPanelLauren]

Hi @brianc

I just wanted to update that this case is marked as complete and resolved in v84 of cPanel which is slated to move to RELEASE this week. I double-checked my test server running v84 and confirmed the newer version of mailman is added:

[root@server ~]# rpm -qa |grep -i mailman
cpanel-mailman-2.1.29-1.cp1178.x86_64

 

[brianc]

Thank you Lauren.

I do have an update with the SSL issue. Running the "/usr/local/cpanel/3rdparty/mailman/bin/withlist -l -r fix_url listname -u list_web_domain" command is only a temporary fix. The non-SSL form element reinserts itself over and over. So something in the cPanel's overnight cronjobs undoes the fix. So as it stands now, there is no permanent way to get older mailman lists to be totally secure via SSL. We are forced to turn off the Force SSL Redirection function for clients that are impacted by this.

 

[cPanelLauren]

Hi @brianc

Interesting, the only mailman specific cron that runs is this one:

45 */4 * * * /usr/bin/test -x /usr/local/cpanel/scripts/update_mailman_cache && /usr/local/cpanel/scripts/update_mailman_cache

This would be running at minute 45 past every 4th hour - so:

16:45:00
20:45:00
00:45:00

If you can confirm it's this cron job that is changing it, I wonder if it might work to automate running the fix_ur_listname script immediately after.