linux systemd privilege escalation exploit
Security researchers have discovered three vulnerabilities in Systemd, a popular init system and service manager for most Linux operating systems, that could allow unprivileged local attackers or malicious programs to gain root access on the targeted systems.

The vulnerabilities, assigned as CVE-2018-16864, CVE-2018-16865, and CVE-2018-16866, actually resides in the "systemd-journald" service that collects information from different sources and creates event logs by logging information in the journal.

The vulnerabilities, which were discovered and reported by security researchers at Qualys, affect all systemd-based Linux distributions, including Redhat and Debian, according to the researchers.

However, some Linux distros such as SUSE Linux Enterprise 15, openSUSE Leap 15.0, and Fedora 28 and 29 are not affected, as "their userspace [code] is compiled with GCC's -fstack-clash-protection."

The first two flaws are memory corruptions issues, while the third one is an out-of-bounds read issue in systemd-journald that can leak sensitive process memory data.

Researchers have successfully created proof-of-concept exploits, which they are planning to release in the near future.

"We developed an exploit for CVE-2018-16865 and CVE-2018-16866 that obtains a local root shell in 10 minutes on i386 and 70 minutes on amd64, on average," the researchers write in an advisory published Wednesday.

CVE-2018-16864 is similar to a Stack Clash vulnerability Qualys researchers discovered in 2017 that can be exploited by malware or low privileged users to escalate their permission to root.

According to the researchers, CVE-2018-16864 existed in systemd's codebase since April 2013 (systemd v203) and became exploitable in February 2016 (systemd v230), while CVE-2018-16865 was introduced in December 2011 (systemd v38) and became exploitable in April 2013 (systemd v201), Qualys says.

However, the third vulnerability (CVE-2018-16866) was introduced in systemd's codebase in June 2015 (systemd v221), but according to the researchers, it was "inadvertently fixed in August 2018."

If you are using a vulnerable Linux system, keep tabs on the latest updates by your respective Linux distribution and install the patches as soon as they are released.

Found this article interesting? Follow us on Twitter and LinkedIn to read more exclusive content we post.