Shulou(Shulou.com)06/01 Report--

This article introduces the relevant knowledge of "how to fix the local rights loophole in the systemd-journald service of Linux system". In the operation of actual cases, many people will encounter such a dilemma, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

0x00 Summary

Qualys Security found three vulnerabilities in systemd-journald

CVE-2018-16864, CVE-2018-16865: memory corruption

CVE-2018-16866: information disclosure (read out of bounds)

Qualys Security said that using CVE-2018-16865 and CVE-2018-16866, it took about 10 minutes for Linux running on i386 architecture to have root permissions, and about 70 minutes for root permissions for Linux running on amd64 architecture (the EXP was not released). If systemd is compiled with the-fstack-clash-protection flag, the vulnerability cannot be exploited (because stack conflicts are prevented, as analyzed below. As you can see, the core of vulnerability exploitation is stack conflicts.

Introduction to 0x01 systemd-journald Service

Systemd-journald is a system service that collects and stores all kinds of log data. It creates and maintains an indexed, structured log database and can collect logs from a variety of different sources:

Collect kernel logs through kmsg

Collect system logs through the syslog interface of libc

Collect structured system logs through the local log interface sd_journal_print

Capture the standard output (STDOUT) and standard error (STDERR) of the service unit

Collect audit records through the kernel audit subsystem

0x02 CVE-2018-16864 analysis

Function

Dispatch_message_real () (journal/journald-server.c) writes to the log by converting each field to a string in the format "=". These strings are constructed using the strjoina () function defined in basic/string-util.h, which uses alloca () to assign the resulting string on the stack.

If an attacker can make the stack conflict with other areas of memory by constructing longer strings, it is possible to overwrite data from other areas, resulting in crash or code execution.

In special cases, a program may have a large cmdline (which can be read through / proc//cmdline), causing stack conflicts, resulting in systemd-journald crashes or code execution.

Utilization

First, send a large, high-priority message to journald from a process with a small cmdline. This message forces a large write / var/log/journal/ operation (between 1MB and 2MB) and forces the creation of a short thread to call fsync to wait for the operation written from memory to disk to complete (important: the stack area of the thread is allocated in the mmap area)

Next, create some processes (32 to 64) to write large files (1MB-- 8MB) to / var/tmp/. These processes allow threads that call fsync in journald to survive longer, making it easier for us to exploit this vulnerability.

Finally, a small, low-priority message is sent to journald through a process. Its cmdline is very large (around 128MB, the distance between the stack area and the mmap area), so that when calling the alloca () function, it can cover the stack space of the calling fsync () thread in journald, resulting in code execution.

0x03 CVE-2018-16865 analysis

The journal_file_append_entry () function in journal-file.c allocates an array of EntryItem structures through alloca () whose number of entries can be controlled by a local attacker.

By directly accessing the UNIX domain socket (default at / run/systemd/journal/socket), an attacker can send many entries to the socket, causing the alloca () function to allocate an array of EntryItem structures to cover other areas of memory. This in turn causes systemd-journald crashes or privilege escalation.

Utilization

First jump to the read and write section of libc and overwrite a function pointer. But this is not easy. Functions called from the "for" loop (in journal_file_append_entry ()) may break bytes below the target function pointer, thus overwriting important libc variables that may crash or deadlock. Therefore, we sometimes have to change our alloca () jump slightly to avoid overwriting these important variables.

We want to overwrite our target function pointer with the address of another function or ROP chain, but unfortunately, the stack frame of the function called in the "for" loop (in journal_file_append_entry ()) does not contain any data we control. However, the 64-bit "hash" value written to alloca () ted "items" is generated by jenkins_hashlittle2 (), which is an unencrypted hash function: we can easily find a short string hash to the specified value (the address that will overwrite our target function pointer), also valid_user_field () (or journal_field_valid ()).

In order to complete our exploitation, we need the stack pointer of journald, as well as the address of the target function pointer in the libc read and write segment, so we need an information disclosure vulnerability.

0x04 CVE-2018-16866 analysis

The syslog_parse_identifier () function in journald-syslog.c does not correctly parse the log string that ends with ":" and returns a pointer that exceeds the limit of the original string. This allows an attacker to exploit this vulnerability to disclose the memory address of the systemd-journal process.

Utilization

Leak stack address or mmap address from journald:

First, send a large local message to / run/systemd/journal/socket; journald will call mmap () to map our message to memory, and then call malloc () to allocate a large number of iovec structures: most of the structure points to the message that we have already mmap (), but a few points to the stack (in dispatch_message_real ()) .iovec array is saved by heap hole when calling free () (after our message is processed in journald)

Next, send a large amount of syslog information to / run/systemd/journal/dev-log;journald to receive a large number of messages from us, call realloc () to get the heap hole that just saved the iovec array (where the mmap and stack pointer are still saved)

Finally, we send a large syslog message using CVE-2018-16866: journald receives a large message in its server buffer (in the heap block that previously contained the iovec array). If we carefully select the size of the message and put its Terminator ":" put it in front of the remaining mmap or stack pointer, then we can leak this pointer (it is misinterpreted as the body of our message)

The combination of 0x05 CVE-2018-16865 and CVE-2018-16866 results in arbitrary code execution

Through CVE-2018-16866 we can get the address of libc, and then with CVE-2018-16865 we can rewrite the pointer of the _ _ free_hook function in libc to the address of the system function, resulting in arbitrary code execution.

Detailed process reference 4

0x06 affects version

CVE-2018-16864 was introduced in April 2013 (systemd v203) and available in February 2016 (systemd v230).

CVE-2018-16865 was introduced in December 2011 (systemd v38) and available in April 2013 (systemd v201).

CVE-2018-16866 was introduced in June 2015 (systemd v221) and inadvertently repaired in August 2018.

Known affected Linux distributions are: Debian,Red Hat,Ubuntu. Please check for yourself whether the version of systemd in your system is affected.

This is the end of the content of "how to fix the local rights loophole in systemd-journald service of Linux system". Thank you for your reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.