Systemd found three vulnerabilities - we figure out what's wrong
At the beginning of the month, Qualys security experts discovered three vulnerabilities in systemd — the Linux initialization subsystem — that allow an attacker to gain superuser rights. We tell what their essence is and what distributions are susceptible to them.
/ Flickr / David Goehring / CC BY / Photo changed
All three vulnerabilities are related to the systemd logging service - journald. The following identifiers were assigned to them in the CVE database: CVE-2018-16864 , CVE-2018-16865, and CVE-2018-16866 . These vulnerabilities give an attacker the opportunity to get root-rights on the attacked system.
All distributions without the user space protection feature ( -fstack-check ) - Debian, Ubuntu, Fedora, CentOS, Mageia, etc. are at risk. Exceptions include SUSE Linux Enterprise 15 and openSUSE Leap 15.0, as well as Fedora versions 28 and 29.
What’s interesting all three vulnerabilities for several years, just about them, nothing was known. CVE-2018-16864 appeared in 2013, but it became possible to exploit it in 2016, when systemd was updated to version 230. CVE-2018-16865 appeared in the operating system in 2011, but became critical only two years after the release of systemd version 201.
As for the third vulnerability (CVE-2018-16866), it has existed since 2015. However, it was accidentally closed by updating systemd v240 a few years later. Machines without this patch are still under threat.
Vulnerability CVE-2018-16864 allows an attacker to manipulate the command line and send multiple arguments (weighing several megabytes) to systemd-journald, thereby causing the process to crash. Next, the hacker has the opportunity to seize control of the extended command index (EIP).
The issue with CVE-2018-16864 is related to writing a large message to / run / systemd / journal / socket. As a result, part of this message goes out of the stack and goes to the mmap region . After that, the attacker can rewrite the read-write segment of the libc and replace the function pointer and run any desired program chain in the system.
As for CVE-2018-16866, it is associated with a parse string error. If you send a special message to the logging system (ending with a colon) in syslog format, the system will ignore the end of the line and write to the log the next part of the stack.
The second and third vulnerabilities allow you to implement a so-called back-to-library attack and launch any functions on the victim's machine. According to experts from Qualys, they managed to create an exploit and get superuser rights on computers with i386 and amd64 architecture in 10 and 70 minutes, respectively.
/ Flickr / bradleypjohnson / CC BY
The last time a vulnerability in systemd was discovered in October 2018. The DHCPv6 client service manager automatically started when a message was received from any DHCP server on the local network or Internet service provider. Using this message in systemd, you could cause a memory failure and gain control of the computer.
Prior to this, several bugs in the code of the service manager were found in 2017. One of them allowed attackers to use TCP packets to execute any code on the system. TCP packets "forced" systemd to allocate too small a buffer for a message. This made it possible to write arbitrary data outside the buffer to the main memory.
Another vulnerability of 2017 was relatedwith unauthorized obtaining superuser rights. In some distributions, such as CentOS and RHEL7, in systemd it was possible to create a profile with a username that starts with a digit. Although usually in Linux this feature is not provided. But if such a user appeared in the system, the service manager gave him administrator rights.
All these vulnerabilities were closed in a short time. “Patches” for new “holes” discovered in January are also gradually appearing. We can expect that soon the vulnerabilities will be closed in most distributions, and administrators of Linux servers and computers will only have to install the system update.
/ Flickr / David Goehring / CC BY / Photo changed
Old new vulnerabilities
All three vulnerabilities are related to the systemd logging service - journald. The following identifiers were assigned to them in the CVE database: CVE-2018-16864 , CVE-2018-16865, and CVE-2018-16866 . These vulnerabilities give an attacker the opportunity to get root-rights on the attacked system.
All distributions without the user space protection feature ( -fstack-check ) - Debian, Ubuntu, Fedora, CentOS, Mageia, etc. are at risk. Exceptions include SUSE Linux Enterprise 15 and openSUSE Leap 15.0, as well as Fedora versions 28 and 29.
What’s interesting all three vulnerabilities for several years, just about them, nothing was known. CVE-2018-16864 appeared in 2013, but it became possible to exploit it in 2016, when systemd was updated to version 230. CVE-2018-16865 appeared in the operating system in 2011, but became critical only two years after the release of systemd version 201.
As for the third vulnerability (CVE-2018-16866), it has existed since 2015. However, it was accidentally closed by updating systemd v240 a few years later. Machines without this patch are still under threat.
What is the essence of the detected "holes"
Vulnerability CVE-2018-16864 allows an attacker to manipulate the command line and send multiple arguments (weighing several megabytes) to systemd-journald, thereby causing the process to crash. Next, the hacker has the opportunity to seize control of the extended command index (EIP).
The issue with CVE-2018-16864 is related to writing a large message to / run / systemd / journal / socket. As a result, part of this message goes out of the stack and goes to the mmap region . After that, the attacker can rewrite the read-write segment of the libc and replace the function pointer and run any desired program chain in the system.
As for CVE-2018-16866, it is associated with a parse string error. If you send a special message to the logging system (ending with a colon) in syslog format, the system will ignore the end of the line and write to the log the next part of the stack.
The second and third vulnerabilities allow you to implement a so-called back-to-library attack and launch any functions on the victim's machine. According to experts from Qualys, they managed to create an exploit and get superuser rights on computers with i386 and amd64 architecture in 10 and 70 minutes, respectively.
“These vulnerabilities are quite serious, given that they allow to increase access rights in the system. The authors still keep the code of their exploit secret, since there are a lot of distributions in there, ”commented Sergey Belkin, head of the IaaS provider development department at 1cloud.ru . - They will publish it when visibility is closed. Some developers, for example from Ubuntu and Red Hat , have already posted the necessary patches. They can be found in official repositories. ”
/ Flickr / bradleypjohnson / CC BY
What other vulnerabilities were found in systemd
The last time a vulnerability in systemd was discovered in October 2018. The DHCPv6 client service manager automatically started when a message was received from any DHCP server on the local network or Internet service provider. Using this message in systemd, you could cause a memory failure and gain control of the computer.
Prior to this, several bugs in the code of the service manager were found in 2017. One of them allowed attackers to use TCP packets to execute any code on the system. TCP packets "forced" systemd to allocate too small a buffer for a message. This made it possible to write arbitrary data outside the buffer to the main memory.
Another vulnerability of 2017 was relatedwith unauthorized obtaining superuser rights. In some distributions, such as CentOS and RHEL7, in systemd it was possible to create a profile with a username that starts with a digit. Although usually in Linux this feature is not provided. But if such a user appeared in the system, the service manager gave him administrator rights.
All these vulnerabilities were closed in a short time. “Patches” for new “holes” discovered in January are also gradually appearing. We can expect that soon the vulnerabilities will be closed in most distributions, and administrators of Linux servers and computers will only have to install the system update.