Bugzilla – Full Text Bug Listing |
Summary: | VUL-0: CVE-2019-3693: mailman: LPE from wwwrun to root; ability to chgrp arbitrary files to mailman | ||
---|---|---|---|
Product: | [Novell Products] SUSE Security Incidents | Reporter: | Johannes Segitz <jsegitz> |
Component: | Audits | Assignee: | Security Team bot <security-team> |
Status: | RESOLVED FIXED | QA Contact: | Security Team bot <security-team> |
Severity: | Normal | ||
Priority: | P3 - Medium | CC: | jsegitz, mcepl, meissner, tchvatal, wolfgang.frisch, wolfgang |
Version: | unspecified | ||
Target Milestone: | --- | ||
Hardware: | Other | ||
OS: | Other | ||
URL: | https://smash.suse.de/issue/245243/ | ||
Whiteboard: | CVSSv3:SUSE:CVE-2019-3693:7.0:(AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H) obs:running:11898:moderate | ||
Found By: | --- | Services Priority: | |
Business Priority: | Blocker: | --- | |
Marketing QA Status: | --- | IT Deployment: | --- |
Bug Depends on: | |||
Bug Blocks: | 1154062 |
Description
Johannes Segitz
2019-10-17 11:13:21 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. (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 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 (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. (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. OK, so what do you think about https://build.suse.de/request/show/205299 and https://build.suse.de/request/show/205298 ? (In reply to Matej Cepl from comment #7) that looks good, thank you 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. 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. This is an autogenerated message for OBS integration: This bug (1154328) was mentioned in https://build.opensuse.org/request/show/766800 15.1 / mailman 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 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 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. 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 (In reply to Johannes Segitz from comment #17) Keeping it open for SLE tracking (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 ??? (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) is fixed |