An issue was discovered in Amanda 3.3.1. A user with backup privileges can trivially compromise a client installation. Amstar is an Amanda Application API script. It should not be run by users directly. It uses star to backup and restore data. It runs binaries with root permissions when parsing the command line argument --star-path.
Created amanda tracking bugs for this issue: Affects: fedora-all [bug 1647094]
There's a public exploit for this issue published here: https://www.exploit-db.com/exploits/39244/ The issue is exploited by running setuid amstar program (that is part of Amanda) with --star-path option, which used to specify path to the star command (/usr/bin/star by default). That way, attacker can instruct amstar to run attacker-controlled program with root privileges. The same problem affects another Amanda program amgtar, using its --gnutar-path option. The problem was fixed in Amanda 3.3.9 by introduction of the /etc/amanda-security.conf configuration file that defines which paths can be used for --star-path and --gnutar-path: https://github.com/zmanda/amanda/blob/tags/community_3_3_9/NEWS Initial commit adding amanda-security.conf file support is: https://github.com/zmanda/amanda/commit/4bf5b9b356848da98560ffbb3a07a9cb5c4ea6d7 For patch backports, other related commits should also be reviewed and considered: https://github.com/zmanda/amanda/commits/tags/community_3_3_9/common-src/security-file.c
This issue affects the versions of amanda as shipped with Red Hat Enterprise Linux 7. The versions of amanda as shipped with Red Hat Enterprise Linux 6 include amstar and amgtar that accept --star-path and --gnutar-path options, but those programs are not installed as setuid root, so they can not be exploited for privilege escalation. The versions of amanda as shipped with Red Hat Enterprise Linux 5 do not include amstar and amgtar. All the setuid programs included in amanda packages in Red Hat Enterprise Linux and Fedora have mode 4750 root:disk. Therefore, those programs can only be run by root or users in the disk group. The amandabackup user created for Amanda is member of the disk group. It should be noted that users in the disk group should be considered root-equivalent, as all disk / partition device files under /dev (such as sd[a-z]*, dm-*) are writeable to the disk group members. Hence there is no real trust boundary crossed if this issue is exploited. Members of the disk group can gain root privileges by directly modifying data on the disk, this issue only gives them an easier easier way to escalate privileges. This has very Low security impact.
There's another reason the amandabackup user / any member of the disk group should be considered root-equivalent when using Amanda prior to 3.3.9. Those users are allowed to do restores (using amgtar / amstar / ambsdtar) and overwrite arbitrary files with arbitrary content. Starting with Amanda 3.3.9, restores are disallowed by default and can be enabled for the amandabackup user using the restore_by_amanda_user option in the amanda-security.conf configuration file.
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s): https://access.redhat.com/security/cve/cve-2016-10730