|Summary:||CVE-2015-7529 sos: Usage of predictable temporary files allows privilege escalation|
|Product:||[Other] Security Response||Reporter:||Adam Mariš <amaris>|
|Component:||vulnerability||Assignee:||Red Hat Product Security <security-response-team>|
|Status:||CLOSED ERRATA||QA Contact:|
|Version:||unspecified||CC:||abaron, agk, aortega, apevec, ayoung, bmr, chrisw, cperry, dallan, dhoward, dkutalek, gavin, gkotton, gmollett, huzaifas, jschluet, lhh, lpeer, lyarwood, markmc, mflitter, mguzik, plambri, pmatouse, pmoravec, rbryant, sbradley, sclewis, security-response-team, tdecacqu|
|Fixed In Version:||Doc Type:||Bug Fix|
An insecure temporary file use flaw was found in the way sos created certain sosreport files. A local attacker could possibly use this flaw to perform a symbolic link attack to reveal the contents of sosreport files, or in some cases modify arbitrary files and escalate their privileges on the system.
|Last Closed:||2016-12-21 01:13:53 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:||1286933, 1286934, 1290953, 1290954, 1290955, 1310409, 1310466|
Description Adam Mariš 2015-11-16 17:14:35 UTC
A vulnerability in sosreport was reported, allowing a privilege escalation to unprivileged attacker on RHEL-6, and change the owner and content of certain files on RHEL-7. sosreport creates temporary directory in /tmp with predictable name sosreport-$hostname-$date with permissions set to 700. Then it creates a tar file with the aforementioned name + .tar suffix. Further it invokes open() with no O_NOFOLLOW nor O_EXCL set, which can be exploited by placing a file or a symlink in its place. Attacker can create his own file to steal the content or can create a symlink to create/modify arbitrary files. On RHEL-7, there is fs.protected_symlinks sysctl provided, which closes this vector. With the setting target of the symlink must match symlink's owner. On RHEL-6 this feature is missing, so the attacker is able to modify arbitrary files and escalate privileges.
Comment 1 Bryn M. Reeves 2015-11-16 18:03:49 UTC
> sosreport creates temporary directory in /tmp with predictable name > sosreport-$hostname-$date" The name of the directory is not predictable - it's the fact that we then re-use that (now published in the file system) name for the final tar archive that allows a malicious user to predict the archive path name. I expect to push a fix for this upstream in the next couple of days however due to product integration needs we may need to use a slightly different approach in any urgent erratas.
Comment 3 Adam Mariš 2015-11-16 18:46:35 UTC
Acknowledgments: This issue was discovered by Mateusz Guzik of Red Hat.
Comment 13 Bryn M. Reeves 2015-11-20 19:04:06 UTC
Created attachment 1097279 [details] [policies] move hash determination to policies
Comment 14 Bryn M. Reeves 2015-11-20 19:04:53 UTC
Created attachment 1097280 [details] [policies] refactor Policy.display_results() args
Comment 15 Bryn M. Reeves 2015-11-20 19:05:27 UTC
Created attachment 1097281 [details] [sosreport] move archive checksumming to sosreport
Comment 16 Bryn M. Reeves 2015-11-20 19:06:16 UTC
Created attachment 1097283 [details] [sosreport] prepare report in a private subdirectory
Comment 25 Huzaifa S. Sidhpurwala 2015-12-01 06:30:46 UTC
Created sos tracking bugs for this issue: Affects: fedora-all [bug 1286934]
Comment 50 Fedora Update System 2015-12-28 22:55:25 UTC
sos-3.2-2.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.
Comment 51 errata-xmlrpc 2016-02-09 08:44:11 UTC
This issue has been addressed in the following products: Red Hat Enterprise Linux 6 Via RHSA-2016:0152 https://rhn.redhat.com/errata/RHSA-2016-0152.html