A systemd-journald exploit

[Anton Maisak]

​https://seclists.org/oss-sec/2019/q1/54

Summary

We discovered three vulnerabilities in systemd-journald (​https://en.wikipedia.org/wiki/Systemd):

• CVE-2018-16864 and CVE-2018-16865, two memory corruptions (attacker-controlled alloca()s);

• CVE-2018-16866, an information leak (an out-of-bounds read).

CVE-2018-16864 was introduced in April 2013 (systemd v203) and became exploitable in February 2016 (systemd v230). We developed a proof of concept for CVE-2018-16864 that gains eip control on i386.

CVE-2018-16865 was introduced in December 2011 (systemd v38) and became exploitable in April 2013 (systemd v201). CVE-2018-16866 was introduced in June 2015 (systemd v221) and was inadvertently fixed in August 2018.

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. We will publish our exploit in the near future.

To the best of our knowledge, all systemd-based Linux distributions are vulnerable, but SUSE Linux Enterprise 15, openSUSE Leap 15.0, and Fedora 28 and 29 are not exploitable because their user space is compiled with GCC's -fstack-clash-protection.

This confirms ​https://grsecurity.net/an_ancient_kernel_hole_is_not_closed.php: "It should be clear that kernel-only attempts to solve [the Stack Clash] will necessarily always be incomplete, as the real issue lies in the lack of stack probing."

[Douglas R. Reno]

I've contacted Qualys to see if I can get the Proof of Concept exploits for i686 and x86_64. On PPC, I cannot verify this bug, as it seems to be unaffected.

Thanks for filing this.

[Anton Maisak]

As I understand, this problems was fixed in systemd git in master soon...

[Douglas R. Reno]

According to ​https://security.archlinux.org/package/systemd, systemd-240 is affected by CVE-2018-16865 and CVE-2018-16864. They mark it as high.

I'll look at backporting the commits as soon as Qualys gets back to me with PoCs. This is one of the few occasions where I'd like to verify for myself that things are fixed before I drop them in. systemd is not a nice daemon to screw up on, similar to if I made a typo in the source of sysvinit.

[Douglas R. Reno]

​https://github.com/systemd/systemd/pull/11374/commits/052c57f132f04a3cf4148f87561618da1a6908b4

 journald: set a limit on the number of fields (1k)

We allocate a iovec entry for each field, so with many short entries,
our memory usage and processing time can be large, even with a relatively
small message size. Let's refuse overly long entries.

CVE-2018-16865
https://bugzilla.redhat.com/show_bug.cgi?id=1653861

What from I can see, the problem is not from an alloca, despite what the CVE
description says, but from the attack multiplication that comes from creating
many very small iovecs: (void* + size_t) for each three bytes of input message.

​https://github.com/systemd/systemd/pull/11374/commits/084eeb865ca63887098e0945fb4e93c852b91b0f

 journald: do not store the iovec entry for process commandline on stack

This fixes a crash where we would read the commandline, whose length is under
control of the sending program, and then crash when trying to create a stack
allocation for it.

CVE-2018-16864
https://bugzilla.redhat.com/show_bug.cgi?id=1653855

The message actually doesn't get written to disk, because
journal_file_append_entry() returns -E2BIG.

These two commits fix our problem.

I'm going to go generate a patch now. I'll run it through a jhalfs build, but I'm not going to verify that it starts. I believe that the reboot after installing the patch in BLFS will suffice.

[Douglas R. Reno]

Fixed at r11500