It was discovered that, when moving problem reports from /var/spool/abrt-upload to /var/spool/abrt or /var/tmp/abrt, abrt-handle-upload does not verify that the new problem directory has appropriate permissions and does not contain symbolic links. A crafted problem report exposes other parts of abrt to attack, and the abrt-handle-upload script allows to overwrite arbitrary files. Acknowledgement: This issue was discovered by Florian Weimer of Red Hat Product Security.
abrt itself does not accept crash uploads over the network, it relies on some sort of file transfer to /var/spool/abrt-upload. By default, this directory has restrictive write permissions, so this functionality is not exposed to users. As a result, this vulnerability does not affect default configurations.
I've opened the following upstream pull request for this CVE: https://github.com/abrt/abrt/pull/955
(In reply to Jakub Filak from comment #3) > I've opened the following upstream pull request for this CVE: > https://github.com/abrt/abrt/pull/955 Thanks, see my Github comments. In short, the directory permissions are unclear, and there seems to be race between the validation and the renaming.
(In reply to Florian Weimer from comment #4) > (In reply to Jakub Filak from comment #3) > > I've opened the following upstream pull request for this CVE: > > https://github.com/abrt/abrt/pull/955 > > Thanks, see my Github comments. In short, the directory permissions are > unclear, and there seems to be race between the validation and the renaming. Thank you! I've updated the pull request and added a comment about the directory permissions.
Upstream commit https://github.com/abrt/abrt/commit/3746b7627218438ae7d781fc8b18a221454e9091 fixes this bug.
This issue has been addressed in the following products: Red Hat Enterprise Linux 7 Via RHSA-2015:1083 https://rhn.redhat.com/errata/RHSA-2015-1083.html
This issue has been addressed in the following products: Red Hat Enterprise Linux 6 Via RHSA-2015:1210 https://rhn.redhat.com/errata/RHSA-2015-1210.html