System Down: A systemd-journald exploit(openwall.com)
openwall.com
System Down: A systemd-journald exploit
https://www.openwall.com/lists/oss-security/2019/01/09/3
344 comments
> If we send a large "native" message to /run/systemd/journal/socket
... the maximum size of a "native" entry is 768MB
Why does journal allow such large messages over a socket? That alone might be a denial-of-service attack; are real messages delayed/blocked if someone sends spawns a bunch of processes that send 768MB of junk to that socket?
[1] https://github.com/systemd/systemd/commit/c4aa09b06f835c91ce...
Why does journal allow such large messages over a socket? That alone might be a denial-of-service attack; are real messages delayed/blocked if someone sends spawns a bunch of processes that send 768MB of junk to that socket?
commit c4aa09b06f835c91cea9e021df4c3605cff2318d
Date: Mon Apr 8 20:32:03 2013 +0200
...
-#define ENTRY_SIZE_MAX (1024*1024*64)
-#define DATA_SIZE_MAX (1024*1024*64)
...
+#define ENTRY_SIZE_MAX (1024*1024*768)
+#define DATA_SIZE_MAX (1024*1024*768)
+/* Make sure not to make this smaller than the maximum coredump
+ * size. See COREDUMP_MAX in coredump.c */
[1] https://github.com/systemd/systemd/commit/c4aa09b06f835c91ce...
Top comment from reddit thread: FWIW distros that use -fstack-clash-protection to compile systemd, including recent Fedora and OpenSUSE, aren't vulnerable.
https://www.reddit.com/r/linux/comments/aeac8g/systemd_earns...
https://www.reddit.com/r/linux/comments/aeac8g/systemd_earns...
These are three long standing exploitable bugs in systemd's journald which can be used to gain local root privileges. Most systemd based distributions are vulnerable and, from the looks of it, may have been for years.
https://wiki.sei.cmu.edu/confluence/display/c/MEM05-C.+Avoid...
> This compliant solution replaces the VLA with a call to malloc(). If malloc() fails, the return value can be checked to prevent the program from terminating abnormally.
Wishful thinking. On overcommit-enabled VM systems (pretty much every GNU/Linux desktop and server by default), malloc will cheerfully return a valid-looking pointer to virtual memory even if the system is out of memory. Your process will get a fatal signal when later it tries to use the memory. It will not be prevented from terminating abnormally.
Any page of the memory could blow up. Maybe the first three pages get a frame just fine, but when the process touches the fourth, it faults.
The reason to use malloc instead of the stack is that it goes awry only when the system is out of memory, not when the stack is out of room.
> This compliant solution replaces the VLA with a call to malloc(). If malloc() fails, the return value can be checked to prevent the program from terminating abnormally.
Wishful thinking. On overcommit-enabled VM systems (pretty much every GNU/Linux desktop and server by default), malloc will cheerfully return a valid-looking pointer to virtual memory even if the system is out of memory. Your process will get a fatal signal when later it tries to use the memory. It will not be prevented from terminating abnormally.
Any page of the memory could blow up. Maybe the first three pages get a frame just fine, but when the process touches the fourth, it faults.
The reason to use malloc instead of the stack is that it goes awry only when the system is out of memory, not when the stack is out of room.
If you're curious to know further critics regarding Systemd, then without-systemd[1] has got you covered.
[1] : http://without-systemd.org/wiki/index.php/Main_Page
[1] : http://without-systemd.org/wiki/index.php/Main_Page
First CVE I've seen to reference a System of a Down song.
(Every subsection starts with an SOAD song quote)
(Every subsection starts with an SOAD song quote)
systemd is interesting as an innovative init/daemon-manager(+), but I remain convinced it's not ideal that it is de facto Linux default init. Surely the default init should be something more manageable (i.e. with fewer attack surfaces) like runit or OpenRC (in combination with something, perhaps runit) or s6 etc.
I might be reading that article wrong, but it reads like they're critical of the use of alloca? I've never really written C or the like, what is dangerous about alloca?
Was systemd ever properly audited? That's exactly why i use devuan as my home server.
Is Coverity being run against systemd? Would it not have found these issues?
I don't see any systems with security releases ready. Did they not notify the effected systems before making it public? I thought that was standard procedure these days.
There is a pattern of designing for the most niche use cases and imposing complexity on everyone by default. Shouldn't it be the other way round? Letting those with advanced needs accept the complexity? Presumably they have the know how.
There are multiple examples of this including the binary journal for those with extreme auditing needs, optimizing for laptop wifi networks when Linux is predominantly used in servers, the ironically named 'predictable network names' that are anything but predictable. And these issues being hand-waved away because of some fringe use case with the additional overhead nonchalantly imposed on all users.
There are multiple examples of this including the binary journal for those with extreme auditing needs, optimizing for laptop wifi networks when Linux is predominantly used in servers, the ironically named 'predictable network names' that are anything but predictable. And these issues being hand-waved away because of some fringe use case with the additional overhead nonchalantly imposed on all users.
I still use ISC DHCP client due to enterprise DHCP using some esoteric DHCP Options that systemd cannot do to this day.
It's been two weeks since the GNU/Linux distributors were notified of this, and still no fixes are available in Redhat/Centos/Debian.
Any ideas about how to mitigate this until official fixes are available? Would it help to block autorestart of journald? Any idea about how to that?
Any ideas about how to mitigate this until official fixes are available? Would it help to block autorestart of journald? Any idea about how to that?
Are there static analysis tools that catch such problems? User controlled buffer length for alloca.
>On a Debian stable (9.5), our proof of concept wins this race and gains eip control after a dozen tries (systemd automatically restarts journald after each crash):
Seems like a good example of why automatically restarting things that crash is a bad idea.
Seems like a good example of why automatically restarting things that crash is a bad idea.
I think that putting a hard limit on alloca allocation size, somewhere around 1-10 Kb, could help prevent this type of exploits. Also, it is possible to write a function that would choose between alloca() and malloc()/free() depending on the size.
How can you check if you systemd is patched ? This sounds very serious.
I refuse to use systemd to this day. It's unbelievably complex and became established through political power play rather than any sort of merit. Which is without a doubt not what I expected to see in the Linux ecosystem.
I suppose prlimit'ing stack size for systemd-journald could work against this exploit too, since clash protection works, but without recompiling anything.
I knew it was a bad exploit when I saw stpcpy() being used in the code. Always use the “n” versions (eg stpncpy()) and measure your sizes!
[deleted]
1. It's reasonable to claim that amd64 (x86_64) is more secure than x86. x86_64 has larger address space, thus higher ASLR entropy. The exploit needs 10 minutes to crack ASLR on x86, but 70 minutes on amd64. If some alert systems have been deploy on the server (attacks need to keep crashing systemd-journald in this process), it buys time. In other cases, it makes exploitation infeasible.
2. CFLAGS hardening works, in addition to ASLR, it's the last line of defense for all C programs. As long as there are still C programs running, patching all memory corruption bugs is impossible. Using mitigation techniques and sandbox-based isolation are the only two ways to limit the damage. All hardening flags should be turned on by all distributions, unless there is a special reason. Fedora turned "-fstack-clash-protection" on since Fedora 28 (https://fedoraproject.org/wiki/Changes/HardeningFlags28).
If you are releasing a C program on Linux, please consider the following,
Major Linux distributions, including Fedora, Debian, Arch Linux, openSUSE are already doing it. Similarly, Firefox and Chromium are using many of these flags too. Unfortunately, Debian did not use `-fstack-clash-protection` and got hit by the exploit, because it was only added since GCC 8.
For a more comprehensive review, check
* Recommended compiler and linker flags for GCC:
https://developers.redhat.com/blog/2018/03/21/compiler-and-l...
* Debian Hardening
https://wiki.debian.org/Hardening