Skip to main content

[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:
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:
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

Comments

6 comments

Date Votes
  • cPanelLauren
    Hi @brianc I remember this thread you had open for the same issue: With that being said I'm curious if the following might be helpful:
    0
  • 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.
    0
  • 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.
    0
  • 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
    0
  • 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.
    0
  • 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.
    0

Please sign in to leave a comment.

Didn't find what you were looking for?

New post