#4408: A systemd-journald exploit
----------------------+-----------------------
Reporter: avmaisak | Owner: renodr
Type: task | Status: assigned
Priority: normal | Milestone: 8.4
Component: Book | Version: SVN
Severity: normal | Resolution:
Keywords: |
----------------------+-----------------------
Comment (by renodr):
[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.
--
Ticket URL: <http://wiki.linuxfromscratch.org/lfs/ticket/4408#comment:4>
LFS Trac <http://wiki.linuxfromscratch.org/lfs/>
Linux From Scratch: Your Distro, Your Rules.
--
http://lists.linuxfromscratch.org/listinfo/lfs-book
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
