Security vulnerabilities never celebrate holidays like New Year’s, and as such, we are already starting 2019 with a huge Linux vulnerability in the systemd portion of the Linux OS. In a 3 CVE assignment (CVE-2018-16864, CVE-2018-16865, and CVE-2018-16866), a vulnerability with system-journald has the potential to collect info from different memory locations and create event logs that log the information into a journal file.
How these attacks occur
First discovered by Qualys, the vulnerability will affect all Linux systems using systemd. Systems with fstack-clash-protection are not affected by this vulnerability, such as SUSE Enterprise 15, openSUSE 15, and Fedora 28 and 29. Memory corruption will occur in addition to an out-of-bounds issue located in system-journald that leaks process memory data. Local root shell can be accessed in 10 minutes on Intel systems and 70 minutes on an AMD system, according to the proof of concept papers that have not yet been published.
The reason the versions of Linux that have fstack-clash-protection enabled avoid being vulnerable is that CVE-2018-16864 is similar to a stack clash vulnerability. These attacks occur when a stack clashes with another memory region that is typically either read only or blank. Once that occurs, the attack then runs the stack pointer to the start of the stack. When this happens, a “jump” over the stack guard page occurs, and you end up in another memory range completely. At this point, you can smash the stack or smash another memory region. With the systemd vulnerability, in boxes that lack fstack-clash-protection, you don’t even need to start with the initial stack clash or running the stack pointer to the start of the stack. The vulnerability that applies to this specific CVE came about in April 2013 but wasn’t exploitable until February 2016. The resulting attack allows for eip (extended instruction pointer) control on i386 systems.
CVE-2018-16865 was introduced into the wild in December of 2011 and has been exploitable since April 2013. Because this version can affect 64bit systems as well, it’s a bit more complex. If you send a large “native” message to the location /run/systemd/journal/socket: and that message exceeds the maximum size of 768MB for a native entry, you can jump from journald’s main stack into the mmap region. This is because if the maximum native entry size is 768MB, and the minimum length of a native item is 3 (“A=\n”), and you factor an EntryItem structure size is 16 (a 64-bit offset and a 64-bit hash), the maximum size of the attacker-controlled alloca() in journal_file_append_entry() is 768MB / 3 * 16 = 4GB, which is more than enough to cause the attack. The 64-bit equation is a bit more complex due to the randomized distance between the main stack and the mmap region being shorter than 4GB with a probability of (approximately)
SUM(d = 0; d < 4GB; d++) d / (16GB * 1TB) ~= 1 / 2048
Full details of the attack can be located in the official breakdown from Qualys. And as always, update, patch, and protect your systems.
OpenLogic open source support gives you access to open source architects and developers who can educate you on this vulnerability, help you to fix it, and cover any issues you run into during or after patching.