systemd 250 and 251 allows local users to achieve a systemd-coredump deadlock by triggering a crash that has a long backtrace. This occurs in parse_elf_object in shared/elf-util.c. The exploitation methodology is to crash a binary calling the same function recursively, and put it in a deeply nested directory to make its backtrace large enough to cause the deadlock. This must be done 16 times when MaxConnections=16 is set for the systemd/units/systemd-coredump.socket file. A flaw was found in the systemd-coredump utility of systemd. When an application crashes, the systemd-coredump utility is called twice, once by the kernel and the second time in the systemd-coredump@.service to write the data, process, and save the core file. Communication between the programs is made through a pipe, and when there is too much data through a long backtrace or many linked libraries, the pipe blocks while waiting for the data, resulting in a timeout of the systemd-coredump@.service.
With Rapid7 live dashboards, I have a clear view of all the assets on my network, which ones can be exploited, and what I need to do in order to reduce the risk in my environment in real-time. No other tool gives us that kind of value and insight.
– Scott Cheney, Manager of Information Security, Sierra View Medical Center