Bug 1647090 (CVE-2016-10730)

Summary: CVE-2016-10730 amanda: Privilege escalation in amstar and amgtar via --*tar-path option
Product: [Other] Security Response Reporter: Laura Pardo <lpardo>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: CLOSED WONTFIX QA Contact:
Severity: low Docs Contact:
Priority: low    
Version: unspecifiedCC: fedora, jridky, j, phracek, rvokal, vdolezal
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: amanda 3.3.9 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-04-22 04:32:12 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On: 1647093, 1647094    
Bug Blocks: 1647095    

Description Laura Pardo 2018-11-06 16:30:47 UTC
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.

Comment 1 Laura Pardo 2018-11-06 16:31:20 UTC
Created amanda tracking bugs for this issue:

Affects: fedora-all [bug 1647094]

Comment 3 Tomas Hoger 2018-11-07 14:10:25 UTC
There's a public exploit for this issue published here:


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:


Initial commit adding amanda-security.conf file support is:


For patch backports, other related commits should also be reviewed and considered:


Comment 4 Tomas Hoger 2018-11-07 14:32:15 UTC
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.

Comment 6 Tomas Hoger 2018-11-09 14:28:47 UTC
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.

Comment 8 Product Security DevOps Team 2020-04-22 04:32:12 UTC
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s):