Create security patch for systemd (CVE-2019-6454)

[Douglas R. Reno]

Create a security patch for CVE-2019-6454:

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.

Remotely-exploitable PID1 crash via D-Bus and subsequent kernel panic.

Date: Mon, 18 Feb 2019 17:41:56 +0100
From: Chris Coulson <chris.coulson@...onical.com>
To: oss-security@...ts.openwall.com
Subject: CVE-2019-6454: systemd (PID1) crash with specially crafted D-Bus
 message

Hi,

I recently discovered a way for an unprivileged user to crash PID1 by sending it a specially crafted D-Bus message on the system bus and causing the stack pointer to jump the stack guard pages, leaving it pointing to an unmapped page.

Details of the issue follow:

----
bus_process_object() in src/libsystemd/sd-bus/bus-objects.c allocates a buffer on the stack large enough to temporarily store the object path specified in the incoming message:

        assert(m->path);
        assert(m->member);

        pl = strlen(m->path);
        do {
=>              char prefix[pl+1];

                bus->nodes_modified = false;

                r = object_find_and_run(bus, m, m->path, false, &found_object);

As the length of this is attacker controlled, it is possible for 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.

According to the dbus specification, the path "may be of any length" (with the length being represented on the wire by a uint32), but systemd seems to limit the size of incoming messages to 128MB (BUS_MESSAGE_SIZE_MAX). From testing on Ubuntu 18.10, it seems that the
real limit is actually much less than this - dbus-daemon drops the connection when I try to send a message with an object path greater than about 32MB. The effect of this is that the stack pointer always lands in an unmapped page and it doesn't seem to be possible to make it land in another mapped page.

Running a simple script that sends a message with a long enough path to org.freedesktop.systemd1 on Ubuntu 18.10 (systemd v239) and CentOS 7.6 (systemd v219) results in an easily reproducible crash (and subsequent kernel panic) on both x86 and x86-64, with a stack trace that looks like this:

Program received signal SIGSEGV, Segmentation fault.                                               
bus_process_object (bus=0x56085041a6a0, m=0x5608504d4d00) at ../src/libsystemd/sd-bus/bus-objects.c:1378 
1378    ../src/libsystemd/sd-bus/bus-objects.c: No such file or directory.                               
(gdb) bt
#0  bus_process_object (bus=0x56085041a6a0, m=0x5608504d4d00) at ../src/libsystemd/sd-bus/bus-objects.c:1378
#1  0x00007f4a4e373b37 in process_message (m=0x5608504d4d00, bus=0x56085041a6a0) at ../src/libsystemd/sd-bus/sd-bus.c:2663
#2  process_running (ret=0x0, priority=0, hint_priority=false, bus=0x56085041a6a0) at ../src/libsystemd/sd-bus/sd-bus.c:2705
#3  bus_process_internal (bus=bus@...ry=0x56085041a6a0, hint_priority=hint_priority@...ry=false, priority=priority@...ry=0,
ret=ret@...ry=0x0) at ../src/libsystemd/sd-bus/sd-bus.c:2924
#4  0x00007f4a4e373d9c in sd_bus_process (bus=bus@...ry=0x56085041a6a0, ret=ret@...ry=0x0) at ../src/libsystemd/sd-bus/sd-bus.c:2951
#5  0x00007f4a4e373e68 in io_callback (s=<optimized out>, fd=<optimized out>, revents=<optimized out>, userdata=<optimized out>, s=<optimized out>, fd=<optimized out>, revents=<optimized out>, userdata=<optimized out>) at ../src/libsystemd/sd-bus/sd-bus.c:3304
#6  0x00007f4a4e34fa10 in source_dispatch (s=s@...ry=0x560850433590) at ../src/libsystemd/sd-event/sd-event.c:3103
#7  0x00007f4a4e34fcff in sd_event_dispatch (e=e@...ry=0x56085036a090) at ../src/libsystemd/sd-event/sd-event.c:3516
#8  0x00007f4a4e34fec8 in sd_event_run (e=0x56085036a090, timeout=18446744073709551615) at ../src/libsystemd/sd-event/sd-event.c:3573
#9  0x000056084e579453 in manager_loop (m=0x5608503675d0) at ../src/core/manager.c:2814
#10 invoke_main_loop (m=0x5608503675d0, ret_reexecute=0x7fff92a0076a, ret_retval=0x7fff92a0076c, ret_shutdown_verb=<optimized out>,
ret_fds=0x7fff92a00770, ret_switch_root_dir=0x7fff92a00798, ret_switch_root_init=0x7fff92a00790, ret_error_message=0x7fff92a00780) at ../src/core/main.c:1630
#11 0x000056084e4da610 in main (argc=<optimized out>, argv=0x7fff92a00a48) at ../src/core/main.c:2415

(gdb) p $_siginfo
$1 = {si_signo = 11, si_errno = 0, si_code = 1, _sifields = {_pad = {-1867007032, 32767, 0 <repeats 26 times>}, _kill = {si_pid =
-1867007032, si_uid = 32767}, _timer = {si_tid = -1867007032, si_overrun = 32767, si_sigval = {sival_int = 0, sival_ptr = 0x0}}, _rt = {si_pid = -1867007032, si_uid = 32767, si_sigval = {sival_int = 0, sival_ptr = 0x0}}, _sigchld = {si_pid = -1867007032, si_uid = 32767, si_status = 0, si_utime = 0, si_stime = 0}, _sigfault = {si_addr = 0x7fff90b7bbc8, _addr_lsb = 0, _addr_bnd = {_lower = 0x0, _upper = 0x0}}, _sigpoll = {si_band = 140735621348296, si_fd = 0}}}

(gdb) disassemble
Dump of assembler code for function bus_process_object:
......
   0x00007f4a4e387aae <+238>:   mov    %r13,%rsi     
   0x00007f4a4e387ab1 <+241>:   mov    %r12,%rdi                           
   0x00007f4a4e387ab4 <+244>:   mov    %rsp,%rbx                            
=> 0x00007f4a4e387ab7 <+247>:   callq  0x7f4a4e386280 <object_find_and_run>

You can see that %rsp points to an unmapped page:

(gdb) info
registers                                                                                 

rax            0x1e84810           32000016
rbx            0x7fff90b7bbd0    140735621348304
rcx            0x0                0
rdx            0x7f4a48dbe028     139957026676776
rsi            0x5608504d4d00     94593706970368
rdi            0x56085041a6a0     94593706206880
rbp            0x7fff92a00430     0x7fff92a00430                                                       
rsp            0x7fff90b7bbd0      0x7fff90b7bbd0
r8             0x7fff92a003f7      140735653348343
r9             0x1                 1
r10            0x1                 1
r11            0x9690b4ffdb710482  -7597373560382749566
r12            0x56085041a6a0      94593706206880
r13            0x5608504d4d00      94593706970368
r14            0x7fff92a003f7      140735653348343
r15            0x7f4a4e465be0      139957117541344
rip            0x7f4a4e387ab7      0x7f4a4e387ab7 <bus_process_object+247>
eflags         0x10202             [ IF RF ]
cs             0x33                51
ss             0x2b                43
ds             0x0                 0
es             0x0                 0
fs             0x0                 0
gs             0x0                 0

(gdb) info proc mappings
process 1

Mapped address spaces:

          Start Addr           End Addr       Size     Offset objfile
......
      0x7f4a4e76f000     0x7f4a4e770000     0x1000    0x29000 /lib/x86_64-linux-gnu/ld-2.28.so
      0x7f4a4e770000     0x7f4a4e771000     0x1000       0x0
      0x7fff929e0000     0x7fff92a01000    0x21000        0x0 [stack]
      0x7fff92ac8000     0x7fff92acb000     0x3000        0x0 [vvar]

Given the constraint that it doesn't appear to be possible to make the stack pointer land in another mapped page, this bug is classified as denial-of-service.
----

There are 3 patches required to resolve this, provided by Red Hat Product Security and attached to this message. The first patch enforces a sensible size limit on D-Bus object paths, dropping messages when the path is too long. The second patch removes usage of variable-size stack allocations for object paths. The third patch stops the system bus connection from being terminated when an invalid message is received.

I would like to thank Riccardo Schirone, Lennart Poettering and Red Hat Product Security for their help with this issue.

I will craft the LFS and BLFS portions of this patch simultaneously and push them as such. ​https://github.com/systemd/systemd/commit/612b74d32f970c43c14ad087ad086424792981b1 ​https://github.com/systemd/systemd/pull/11754

[Douglas R. Reno]

Fixed at r11553