From ${URL} : The following flaws were reported by Tavis Oramandy: Furthermore, Abrt suffers from numerous race conditions and symlink problems from trusting unprivileged programs. For example, the code below (and lots of similar code) is vulnerable to a filesystem race where a user unlinks the file after the copy but before the chown. https://github.com/abrt/abrt/blob/master/src/hooks/abrt-hook-ccpp.c#L634 strcpy(source_filename + source_base_ofs, "maps"); strcpy(dest_base, FILENAME_MAPS); copy_file(source_filename, dest_filename, DEFAULT_DUMP_DIR_MODE); IGNORE_RESULT(chown(dest_filename, dd->dd_uid, dd->dd_gid)); This code trusts various symlinks in /tmp without validation: https://github.com/abrt/abrt/blob/master/src/hooks/abrt-hook-ccpp.c#L806 char *java_log = xasprintf("/tmp/jvm-%lu/hs_error.log", (long)pid); int src_fd = open(java_log, O_RDONLY); free(java_log); This code trusts the /proc/pid/exe symlink, even though it is possible to link it anywhere you want. https://github.com/abrt/abrt/blob/master/src/hooks/abrt-hook-ccpp.c#L368 sprintf(buf, "/proc/%lu/exe", (long)pid); int src_fd_binary = open(buf, O_RDONLY); /* might fail and return -1, it's ok */ This code trusts the attacker controlled root symlink and copies files from it. https://github.com/abrt/libreport/blob/master/src/lib/dump_dir.c#L671 if (chroot_dir) copy_file_from_chroot(dd, FILENAME_OS_INFO_IN_ROOTDIR, chroot_dir, "/etc/os-release"); This instructs librpm to trust an unprivileged root symlink: https://github.com/abrt/abrt/blob/master/src/daemon/rpm.c#L184 if (rpmtsSetRootDir(*ts, rootdir_or_NULL) != 0) { rpmtsFree(*ts); return -1; } And so on. There are other automatic crash analysis scripts, I believe systemd also has one - I haven't looked at it all. Mitigation: It is recommended to disable abrt via the following command line, till the flaws have been resolved: sysctl -w kern.core_pattern=core Note: This will reset, if abrt is re-started. @maintainer(s): after the bump, in case we need to stabilize the package, please let us know if it is ready for the stabilization or not.
Is our really old version also affected by this? (at least the systemd part probably not). Anyway this is problematic as it's hard to bump... (other option would be to try to backport the patches) :S
@ Maintainer(s): Yes, we are affected. The vulnerable function was introduced in commit 0179d4abbda0fcff6c6f9fba706a4a9101d219c5 ... $ git tag --contains 0179d4abbda0fcff6c6f9fba706a4a9101d219c5 | sort 1.1.10 1.1.11 1.1.12 1.1.13 1.1.14 1.1.15 1.1.16 1.1.17 1.1.18 1.1.5 1.1.6 1.1.7 1.1.8 1.1.9 2.0.0 2.0.1 2.0.10 2.0.11 2.0.12 <<<<< 2.0.13 [...] To fix this problem you have at least to bump to =app-admin/abrt-2.1.11-20.el7 Will you do that for us?
@gnome, ping.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=48ba7760fa6b26b4413be0125a7c9517f9bce8cb commit 48ba7760fa6b26b4413be0125a7c9517f9bce8cb Author: Aaron Bauman <bman@gentoo.org> AuthorDate: 2018-05-23 22:43:42 +0000 Commit: Aaron Bauman <bman@gentoo.org> CommitDate: 2018-05-23 22:43:42 +0000 app-admin/abrt: bumpity bump bump Bug: https://bugs.gentoo.org/546798 Bug: https://bugs.gentoo.org/546912 Closes: https://bugs.gentoo.org/451742 Package-Manager: Portage-2.3.38, Repoman-2.3.9 app-admin/abrt/Manifest | 1 + app-admin/abrt/abrt-2.10.9.ebuild | 113 ++++++++++++++++++++++++++++++++++++++ 2 files changed, 114 insertions(+)
cleanup in bug #546912
