#4428: Create security patch for systemd (CVE-2019-6454) --------------------+---------------------- Reporter: renodr | Owner: lfs-book Type: task | Status: new Priority: high | Milestone: 8.4 Component: Book | Version: SVN Severity: normal | Keywords: --------------------+---------------------- 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.coul...@...onical.com> To: oss-secur...@...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=b...@...ry=0x56085041a6a0, hint_priority=hint_prior...@...ry=false, priority=prior...@...ry=0, ret=r...@...ry=0x0) at ../src/libsystemd/sd-bus/sd-bus.c:2924 #4 0x00007f4a4e373d9c in sd_bus_process (bus=b...@...ry=0x56085041a6a0, ret=r...@...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] -- Ticket URL: <http://wiki.linuxfromscratch.org/lfs/ticket/4428> LFS Trac <http://wiki.linuxfromscratch.org/lfs/> Linux From Scratch: Your Distro, Your Rules. -- http://lists.linuxfromscratch.org/listinfo/lfs-book FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page