It was discovered that the glusterfs.spec file writes a shell script under a predictable temporary name. A local attacker could potentially use this flaw to escalate their privileges to root by modifying the shell script during the installation of the glusterfs packages. The vulnerable code is: -- rpm in RHEL5 does not have os.tmpname() -- io.tmpfile() can not be resolved to a filename to pass to bash :-/ tmpname = "/tmp/glusterfs_pretrans_" .. os.date("%s") tmpfile = io.open(tmpname, "w") tmpfile:write(script) tmpfile:close() ok, how, val = os.execute("/bin/bash " .. tmpname)
Acknowledgements: This issue was discovered by Florian Weimer of Red Hat Product Security.
We can easily avoid this in RHEL 6/7 by using something like: if (SomeFunc ~= nil) then SomeFunc(Args) end and then for RHEL 5 we can use a made up /tmp thing that is a bit safer like maybe math.random or read from /dev/random and create a string from that.
This only affects Gluster packages built with the -server sub package.
Analysis -------- Spec file of the glusterfs writes a file with a predictable name in /tmp as /tmp/glusterfs_pretrans_ as this is executed during installation or when updating the glusterfs package. An attacker can execute a targeted attack by replacing contents of glusterfs_pretrans_ file by malicious code to escalate privileges on the system.
(In reply to Kurt Seifried from comment #3) > This only affects Gluster packages built with the -server sub package. All %pretrans scripts, which are only available while doing a server-side RPM build, use this mechanism of writing a shell script to a temporary file and then execute it. Would it be safe to assume that fixing all such %pretrans scripts for all glusterfs sub packages would be a sensible thing to do? Also, the glusterfs build on rhel 5 is a client only build and the %pretrans scripts with this security issue are available only for server-side RPM builds on rhel 6 and rhel 7. Since os.tmpname() is available on rhel 6 and rhel 7, would using the file name returned by os.tmpname() fix the security issue?
This issue has been addressed in the following products: Red Hat Gluster Storage 3.2 for RHEL 6 Native Client for RHEL 6 for Red Hat Storage Via RHSA-2017:0484 https://rhn.redhat.com/errata/RHSA-2017-0484.html
This issue has been addressed in the following products: Red Hat Gluster Storage 3.2 for RHEL 7 Native Client for RHEL 7 for Red Hat Storage Via RHSA-2017:0486 https://rhn.redhat.com/errata/RHSA-2017-0486.html
Statement: This issue did not affect the versions of glusterfs as shipped with Red Hat Enterprise Linux 6, and 7.