|Summary:||CVE-2019-6454 systemd: Insufficient input validation in bus_process_object() resulting in PID 1 crash|
|Product:||[Other] Security Response||Reporter:||Andrej Nemec <anemec>|
|Component:||vulnerability||Assignee:||Red Hat Product Security <security-response-team>|
|Status:||NEW ---||QA Contact:|
|Version:||unspecified||CC:||abhgupta, bmcclain, cperry, dbaker, dblechte, dfediuck, eedri, ego.cordatus, jokerman, kent, lnykryn, lpoetter, mgoldboi, michal.skrivanek, msekleta, rschiron, sbonazzo, security-response-team, sherold, ssahani, s, sthangav, systemd-maint-list, systemd-maint, trankin, yturgema, zbyszek, zjedrzej|
|Fixed In Version:||Doc Type:||If docs needed, set a value|
It was discovered that systemd allocates a buffer large enough to store the path field of a dbus message without performing enough checks. A local attacker may trigger this flaw by sending a dbus message to systemd with a large path making systemd crash or possibly elevating his privileges.
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:||1667871, 1678641, 1710103, 1710104, 1667870, 1678394, 1679414, 1679415, 1693971|
Description Andrej Nemec 2019-01-17 09:53:09 UTC
It was found that bus_process_object() in bus-objects.c allocates a buffer on the stack large enough to temporarily store the object path specified in the incoming message. A malicious unprivileged local user to send a message which results in the stack pointer moving outside of the bounds of the currently mapped stack region, jumping over the stack guard pages. A specifically crafted DBUS nessage could crash PID 1 and result in a subsequent kernel panic.
Comment 1 Riccardo Schirone 2019-01-17 16:13:12 UTC
systemd tries to setup a signal handler to intercept segmentation faults and spawn a shell in case of crashes, however due to the nature of the flaw, the kernel is not able to call the handler and it just makes PID 1 crash with a subsequent kernel panic.
Comment 2 Riccardo Schirone 2019-01-18 07:56:17 UTC
Acknowledgments: Name: Chris Coulson (Ubuntu Security)
Comment 5 Riccardo Schirone 2019-01-18 15:05:50 UTC
Given enough preconditions, we do not exclude an attacker may be able to use this flaw to execute code and escalate his privileges, as done in other stack clashing attacks. However this would require a precise attack as once systemd crashes, the entire system needs to be restarted. We do not have proofs of such attacks.
Comment 6 Riccardo Schirone 2019-01-21 10:24:19 UTC
Fedora 28/29 binaries are compiled with -fstack-clash-protection gcc option, thus making the Impact on those systems slightly lower. An attacker can only make systemd crash, with consequent system freeze, but he cannot use it to skip the stack guard page and make the stack clash with any other memory region.
Comment 9 Pedro Sampaio 2019-02-18 16:54:53 UTC
Created systemd tracking bugs for this issue: Affects: fedora-all [bug 1678394]
Comment 11 Riccardo Schirone 2019-02-19 09:49:21 UTC
Comment 12 errata-xmlrpc 2019-02-19 10:29:44 UTC
This issue has been addressed in the following products: Red Hat Enterprise Linux 7 Via RHSA-2019:0368 https://access.redhat.com/errata/RHSA-2019:0368
Comment 13 Riccardo Schirone 2019-02-19 10:45:03 UTC
Comment 14 Doran Moppert 2019-02-21 06:17:06 UTC
Statement: This vulnerability is present in Red Hat Virtualization Hypervisor and Management Appliance, however it can only be exploited locally. Since these systems do not typically have local user accounts, this issue has been rated Moderate severity for Red Hat Virtualization 4.
Comment 16 errata-xmlrpc 2019-03-05 11:09:21 UTC
This issue has been addressed in the following products: Red Hat Virtualization 4 for Red Hat Enterprise Linux 7 Via RHSA-2019:0457 https://access.redhat.com/errata/RHSA-2019:0457
Comment 17 errata-xmlrpc 2019-03-05 11:09:41 UTC
This issue has been addressed in the following products: Red Hat Virtualization 4 for Red Hat Enterprise Linux 7 Via RHSA-2019:0461 https://access.redhat.com/errata/RHSA-2019:0461