* [Buildroot] [PATCH 1/1] package/systemd: add upstream fix for CVE-2018-16864
@ 2019-01-11 7:54 james.hilliard1 at gmail.com
2019-01-11 10:46 ` Peter Korsgaard
0 siblings, 1 reply; 9+ messages in thread
From: james.hilliard1 at gmail.com @ 2019-01-11 7:54 UTC (permalink / raw)
To: buildroot
From: James Hilliard <james.hilliard1@gmail.com>
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
---
...-not-store-the-iovec-entry-for-process-co.patch | 205 +++++++++++++++++++++
1 file changed, 205 insertions(+)
create mode 100644 package/systemd/0004-journald-do-not-store-the-iovec-entry-for-process-co.patch
diff --git a/package/systemd/0004-journald-do-not-store-the-iovec-entry-for-process-co.patch b/package/systemd/0004-journald-do-not-store-the-iovec-entry-for-process-co.patch
new file mode 100644
index 0000000..dbf9bb5
--- /dev/null
+++ b/package/systemd/0004-journald-do-not-store-the-iovec-entry-for-process-co.patch
@@ -0,0 +1,205 @@
+From 084eeb865ca63887098e0945fb4e93c852b91b0f Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Zbigniew=20J=C4=99drzejewski-Szmek?= <zbyszek@in.waw.pl>
+Date: Wed, 5 Dec 2018 18:38:39 +0100
+Subject: [PATCH] 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.
+
+[james.hilliard1 at gmail.com: backport from upstream commit
+084eeb865ca63887098e0945fb4e93c852b91b0f]
+Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
+---
+ src/basic/io-util.c | 10 ++++++++++
+ src/basic/io-util.h | 2 ++
+ src/coredump/coredump.c | 31 +++++++++++--------------------
+ src/journal/journald-server.c | 25 +++++++++++++++----------
+ 4 files changed, 38 insertions(+), 30 deletions(-)
+
+diff --git a/src/basic/io-util.c b/src/basic/io-util.c
+index 1f64cc9..575398f 100644
+--- a/src/basic/io-util.c
++++ b/src/basic/io-util.c
+@@ -8,6 +8,7 @@
+ #include <unistd.h>
+
+ #include "io-util.h"
++#include "string-util.h"
+ #include "time-util.h"
+
+ int flush_fd(int fd) {
+@@ -252,3 +253,12 @@ ssize_t sparse_write(int fd, const void *p, size_t sz, size_t run_length) {
+
+ return q - (const uint8_t*) p;
+ }
++
++char* set_iovec_string_field(struct iovec *iovec, size_t *n_iovec, const char *field, const char *value) {
++ char *x;
++
++ x = strappend(field, value);
++ if (x)
++ iovec[(*n_iovec)++] = IOVEC_MAKE_STRING(x);
++ return x;
++}
+diff --git a/src/basic/io-util.h b/src/basic/io-util.h
+index ed189b5..792a64a 100644
+--- a/src/basic/io-util.h
++++ b/src/basic/io-util.h
+@@ -71,3 +71,5 @@ static inline bool FILE_SIZE_VALID_OR_INFINITY(uint64_t l) {
+ #define IOVEC_MAKE(base, len) (struct iovec) IOVEC_INIT(base, len)
+ #define IOVEC_INIT_STRING(string) IOVEC_INIT((char*) string, strlen(string))
+ #define IOVEC_MAKE_STRING(string) (struct iovec) IOVEC_INIT_STRING(string)
++
++char* set_iovec_string_field(struct iovec *iovec, size_t *n_iovec, const char *field, const char *value);
+diff --git a/src/coredump/coredump.c b/src/coredump/coredump.c
+index 20c1fb0..db2cf64 100644
+--- a/src/coredump/coredump.c
++++ b/src/coredump/coredump.c
+@@ -1063,19 +1063,10 @@ static int send_iovec(const struct iovec iovec[], size_t n_iovec, int input_fd)
+ return 0;
+ }
+
+-static char* set_iovec_field(struct iovec *iovec, size_t *n_iovec, const char *field, const char *value) {
+- char *x;
+-
+- x = strappend(field, value);
+- if (x)
+- iovec[(*n_iovec)++] = IOVEC_MAKE_STRING(x);
+- return x;
+-}
+-
+ static char* set_iovec_field_free(struct iovec *iovec, size_t *n_iovec, const char *field, char *value) {
+ char *x;
+
+- x = set_iovec_field(iovec, n_iovec, field, value);
++ x = set_iovec_string_field(iovec, n_iovec, field, value);
+ free(value);
+ return x;
+ }
+@@ -1125,36 +1116,36 @@ static int gather_pid_metadata(
+ disable_coredumps();
+ }
+
+- set_iovec_field(iovec, n_iovec, "COREDUMP_UNIT=", context[CONTEXT_UNIT]);
++ set_iovec_string_field(iovec, n_iovec, "COREDUMP_UNIT=", context[CONTEXT_UNIT]);
+ }
+
+ if (cg_pid_get_user_unit(pid, &t) >= 0)
+ set_iovec_field_free(iovec, n_iovec, "COREDUMP_USER_UNIT=", t);
+
+ /* The next few are mandatory */
+- if (!set_iovec_field(iovec, n_iovec, "COREDUMP_PID=", context[CONTEXT_PID]))
++ if (!set_iovec_string_field(iovec, n_iovec, "COREDUMP_PID=", context[CONTEXT_PID]))
+ return log_oom();
+
+- if (!set_iovec_field(iovec, n_iovec, "COREDUMP_UID=", context[CONTEXT_UID]))
++ if (!set_iovec_string_field(iovec, n_iovec, "COREDUMP_UID=", context[CONTEXT_UID]))
+ return log_oom();
+
+- if (!set_iovec_field(iovec, n_iovec, "COREDUMP_GID=", context[CONTEXT_GID]))
++ if (!set_iovec_string_field(iovec, n_iovec, "COREDUMP_GID=", context[CONTEXT_GID]))
+ return log_oom();
+
+- if (!set_iovec_field(iovec, n_iovec, "COREDUMP_SIGNAL=", context[CONTEXT_SIGNAL]))
++ if (!set_iovec_string_field(iovec, n_iovec, "COREDUMP_SIGNAL=", context[CONTEXT_SIGNAL]))
+ return log_oom();
+
+- if (!set_iovec_field(iovec, n_iovec, "COREDUMP_RLIMIT=", context[CONTEXT_RLIMIT]))
++ if (!set_iovec_string_field(iovec, n_iovec, "COREDUMP_RLIMIT=", context[CONTEXT_RLIMIT]))
+ return log_oom();
+
+- if (!set_iovec_field(iovec, n_iovec, "COREDUMP_HOSTNAME=", context[CONTEXT_HOSTNAME]))
++ if (!set_iovec_string_field(iovec, n_iovec, "COREDUMP_HOSTNAME=", context[CONTEXT_HOSTNAME]))
+ return log_oom();
+
+- if (!set_iovec_field(iovec, n_iovec, "COREDUMP_COMM=", context[CONTEXT_COMM]))
++ if (!set_iovec_string_field(iovec, n_iovec, "COREDUMP_COMM=", context[CONTEXT_COMM]))
+ return log_oom();
+
+ if (context[CONTEXT_EXE] &&
+- !set_iovec_field(iovec, n_iovec, "COREDUMP_EXE=", context[CONTEXT_EXE]))
++ !set_iovec_string_field(iovec, n_iovec, "COREDUMP_EXE=", context[CONTEXT_EXE]))
+ return log_oom();
+
+ if (sd_pid_get_session(pid, &t) >= 0)
+@@ -1222,7 +1213,7 @@ static int gather_pid_metadata(
+ iovec[(*n_iovec)++] = IOVEC_MAKE_STRING(t);
+
+ if (safe_atoi(context[CONTEXT_SIGNAL], &signo) >= 0 && SIGNAL_VALID(signo))
+- set_iovec_field(iovec, n_iovec, "COREDUMP_SIGNAL_NAME=SIG", signal_to_string(signo));
++ set_iovec_string_field(iovec, n_iovec, "COREDUMP_SIGNAL_NAME=SIG", signal_to_string(signo));
+
+ return 0; /* we successfully acquired all metadata */
+ }
+diff --git a/src/journal/journald-server.c b/src/journal/journald-server.c
+index f096725..2a960eb 100644
+--- a/src/journal/journald-server.c
++++ b/src/journal/journald-server.c
+@@ -905,6 +905,7 @@ static void dispatch_message_real(
+ pid_t object_pid) {
+
+ char source_time[sizeof("_SOURCE_REALTIME_TIMESTAMP=") + DECIMAL_STR_MAX(usec_t)];
++ _cleanup_free_ char *cmdline1 = NULL, *cmdline2 = NULL;
+ uid_t journal_uid;
+ ClientContext *o;
+
+@@ -921,20 +922,23 @@ static void dispatch_message_real(
+ IOVEC_ADD_NUMERIC_FIELD(iovec, n, c->uid, uid_t, uid_is_valid, UID_FMT, "_UID");
+ IOVEC_ADD_NUMERIC_FIELD(iovec, n, c->gid, gid_t, gid_is_valid, GID_FMT, "_GID");
+
+- IOVEC_ADD_STRING_FIELD(iovec, n, c->comm, "_COMM");
+- IOVEC_ADD_STRING_FIELD(iovec, n, c->exe, "_EXE");
+- IOVEC_ADD_STRING_FIELD(iovec, n, c->cmdline, "_CMDLINE");
+- IOVEC_ADD_STRING_FIELD(iovec, n, c->capeff, "_CAP_EFFECTIVE");
++ IOVEC_ADD_STRING_FIELD(iovec, n, c->comm, "_COMM"); /* At most TASK_COMM_LENGTH (16 bytes) */
++ IOVEC_ADD_STRING_FIELD(iovec, n, c->exe, "_EXE"); /* A path, so at most PATH_MAX (4096 bytes) */
+
+- IOVEC_ADD_SIZED_FIELD(iovec, n, c->label, c->label_size, "_SELINUX_CONTEXT");
++ if (c->cmdline)
++ /* At most _SC_ARG_MAX (2MB usually), which is too much to put on stack.
++ * Let's use a heap allocation for this one. */
++ cmdline1 = set_iovec_string_field(iovec, &n, "_CMDLINE=", c->cmdline);
+
++ IOVEC_ADD_STRING_FIELD(iovec, n, c->capeff, "_CAP_EFFECTIVE"); /* Read from /proc/.../status */
++ IOVEC_ADD_SIZED_FIELD(iovec, n, c->label, c->label_size, "_SELINUX_CONTEXT");
+ IOVEC_ADD_NUMERIC_FIELD(iovec, n, c->auditid, uint32_t, audit_session_is_valid, "%" PRIu32, "_AUDIT_SESSION");
+ IOVEC_ADD_NUMERIC_FIELD(iovec, n, c->loginuid, uid_t, uid_is_valid, UID_FMT, "_AUDIT_LOGINUID");
+
+- IOVEC_ADD_STRING_FIELD(iovec, n, c->cgroup, "_SYSTEMD_CGROUP");
++ IOVEC_ADD_STRING_FIELD(iovec, n, c->cgroup, "_SYSTEMD_CGROUP"); /* A path */
+ IOVEC_ADD_STRING_FIELD(iovec, n, c->session, "_SYSTEMD_SESSION");
+ IOVEC_ADD_NUMERIC_FIELD(iovec, n, c->owner_uid, uid_t, uid_is_valid, UID_FMT, "_SYSTEMD_OWNER_UID");
+- IOVEC_ADD_STRING_FIELD(iovec, n, c->unit, "_SYSTEMD_UNIT");
++ IOVEC_ADD_STRING_FIELD(iovec, n, c->unit, "_SYSTEMD_UNIT"); /* Unit names are bounded by UNIT_NAME_MAX */
+ IOVEC_ADD_STRING_FIELD(iovec, n, c->user_unit, "_SYSTEMD_USER_UNIT");
+ IOVEC_ADD_STRING_FIELD(iovec, n, c->slice, "_SYSTEMD_SLICE");
+ IOVEC_ADD_STRING_FIELD(iovec, n, c->user_slice, "_SYSTEMD_USER_SLICE");
+@@ -955,13 +959,14 @@ static void dispatch_message_real(
+ IOVEC_ADD_NUMERIC_FIELD(iovec, n, o->uid, uid_t, uid_is_valid, UID_FMT, "OBJECT_UID");
+ IOVEC_ADD_NUMERIC_FIELD(iovec, n, o->gid, gid_t, gid_is_valid, GID_FMT, "OBJECT_GID");
+
++ /* See above for size limits, only ->cmdline may be large, so use a heap allocation for it. */
+ IOVEC_ADD_STRING_FIELD(iovec, n, o->comm, "OBJECT_COMM");
+ IOVEC_ADD_STRING_FIELD(iovec, n, o->exe, "OBJECT_EXE");
+- IOVEC_ADD_STRING_FIELD(iovec, n, o->cmdline, "OBJECT_CMDLINE");
+- IOVEC_ADD_STRING_FIELD(iovec, n, o->capeff, "OBJECT_CAP_EFFECTIVE");
++ if (o->cmdline)
++ cmdline2 = set_iovec_string_field(iovec, &n, "OBJECT_CMDLINE=", o->cmdline);
+
++ IOVEC_ADD_STRING_FIELD(iovec, n, o->capeff, "OBJECT_CAP_EFFECTIVE");
+ IOVEC_ADD_SIZED_FIELD(iovec, n, o->label, o->label_size, "OBJECT_SELINUX_CONTEXT");
+-
+ IOVEC_ADD_NUMERIC_FIELD(iovec, n, o->auditid, uint32_t, audit_session_is_valid, "%" PRIu32, "OBJECT_AUDIT_SESSION");
+ IOVEC_ADD_NUMERIC_FIELD(iovec, n, o->loginuid, uid_t, uid_is_valid, UID_FMT, "OBJECT_AUDIT_LOGINUID");
+
+--
+2.7.4
+
--
2.7.4
^ permalink raw reply related [flat|nested] 9+ messages in thread
* [Buildroot] [PATCH 1/1] package/systemd: add upstream fix for CVE-2018-16864
2019-01-11 7:54 [Buildroot] [PATCH 1/1] package/systemd: add upstream fix for CVE-2018-16864 james.hilliard1 at gmail.com
@ 2019-01-11 10:46 ` Peter Korsgaard
2019-01-11 11:03 ` James Hilliard
0 siblings, 1 reply; 9+ messages in thread
From: Peter Korsgaard @ 2019-01-11 10:46 UTC (permalink / raw)
To: buildroot
>>>>> "james" == james hilliard1 <james.hilliard1@gmail.com> writes:
> From: James Hilliard <james.hilliard1@gmail.com>
> Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
> ---
> ...-not-store-the-iovec-entry-for-process-co.patch | 205 +++++++++++++++++++++
> 1 file changed, 205 insertions(+)
> create mode 100644 package/systemd/0004-journald-do-not-store-the-iovec-entry-for-process-co.patch
> diff --git
> a/package/systemd/0004-journald-do-not-store-the-iovec-entry-for-process-co.patch
> b/package/systemd/0004-journald-do-not-store-the-iovec-entry-for-process-co.patch
> new file mode 100644
> index 0000000..dbf9bb5
> --- /dev/null
> +++ b/package/systemd/0004-journald-do-not-store-the-iovec-entry-for-process-co.patch
> @@ -0,0 +1,205 @@
> +From 084eeb865ca63887098e0945fb4e93c852b91b0f Mon Sep 17 00:00:00 2001
> +From: =?UTF-8?q?Zbigniew=20J=C4=99drzejewski-Szmek?= <zbyszek@in.waw.pl>
> +Date: Wed, 5 Dec 2018 18:38:39 +0100
> +Subject: [PATCH] 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.
> +
> +[james.hilliard1 at gmail.com: backport from upstream commit
> +084eeb865ca63887098e0945fb4e93c852b91b0f]
> +Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
The "standard way" to backport is to use git cherry-pick -sx which adds
a line like:
(cherry picked from commit 084eeb865ca63887098e0945fb4e93c852b91b0f)
What about CVE-2018-16865, E.G. commit 052c57f132f04a / ef4d6abe7c7fa?
Do those not apply to 240?
--
Bye, Peter Korsgaard
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Buildroot] [PATCH 1/1] package/systemd: add upstream fix for CVE-2018-16864
2019-01-11 10:46 ` Peter Korsgaard
@ 2019-01-11 11:03 ` James Hilliard
2019-01-11 11:34 ` Peter Korsgaard
0 siblings, 1 reply; 9+ messages in thread
From: James Hilliard @ 2019-01-11 11:03 UTC (permalink / raw)
To: buildroot
On Fri, Jan 11, 2019 at 3:46 AM Peter Korsgaard <peter@korsgaard.com> wrote:
>
> >>>>> "james" == james hilliard1 <james.hilliard1@gmail.com> writes:
>
> > From: James Hilliard <james.hilliard1@gmail.com>
> > Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
> > ---
> > ...-not-store-the-iovec-entry-for-process-co.patch | 205 +++++++++++++++++++++
> > 1 file changed, 205 insertions(+)
> > create mode 100644 package/systemd/0004-journald-do-not-store-the-iovec-entry-for-process-co.patch
>
> > diff --git
> > a/package/systemd/0004-journald-do-not-store-the-iovec-entry-for-process-co.patch
> > b/package/systemd/0004-journald-do-not-store-the-iovec-entry-for-process-co.patch
> > new file mode 100644
> > index 0000000..dbf9bb5
> > --- /dev/null
> > +++ b/package/systemd/0004-journald-do-not-store-the-iovec-entry-for-process-co.patch
> > @@ -0,0 +1,205 @@
> > +From 084eeb865ca63887098e0945fb4e93c852b91b0f Mon Sep 17 00:00:00 2001
> > +From: =?UTF-8?q?Zbigniew=20J=C4=99drzejewski-Szmek?= <zbyszek@in.waw.pl>
> > +Date: Wed, 5 Dec 2018 18:38:39 +0100
> > +Subject: [PATCH] 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.
> > +
> > +[james.hilliard1 at gmail.com: backport from upstream commit
> > +084eeb865ca63887098e0945fb4e93c852b91b0f]
> > +Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
>
> The "standard way" to backport is to use git cherry-pick -sx which adds
> a line like:
Patch format in buildroot seems to be fairly inconstant. I think this
format was what I was recommended to use last.
>
> (cherry picked from commit 084eeb865ca63887098e0945fb4e93c852b91b0f)
>
> What about CVE-2018-16865, E.G. commit 052c57f132f04a / ef4d6abe7c7fa?
> Do those not apply to 240?
So here https://www.qualys.com/2019/01/09/system-down/system-down.txt it says:
"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."
So my assumption was that we didn't need patches for CVE-2018-16865
since systemd 240 was released in Dec 2018.
>
> --
> Bye, Peter Korsgaard
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Buildroot] [PATCH 1/1] package/systemd: add upstream fix for CVE-2018-16864
2019-01-11 11:03 ` James Hilliard
@ 2019-01-11 11:34 ` Peter Korsgaard
2019-01-11 11:36 ` James Hilliard
0 siblings, 1 reply; 9+ messages in thread
From: Peter Korsgaard @ 2019-01-11 11:34 UTC (permalink / raw)
To: buildroot
>>>>> "James" == James Hilliard <james.hilliard1@gmail.com> writes:
Hi,
>> > +[james.hilliard1 at gmail.com: backport from upstream commit
>> > +084eeb865ca63887098e0945fb4e93c852b91b0f]
>> > +Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
>>
>> The "standard way" to backport is to use git cherry-pick -sx which adds
>> a line like:
> Patch format in buildroot seems to be fairly inconstant. I think this
> format was what I was recommended to use last.
True. As systemd is maintained in git, it IMHO makes sense to use the
normal git format.
>> What about CVE-2018-16865, E.G. commit 052c57f132f04a / ef4d6abe7c7fa?
>> Do those not apply to 240?
> So here https://www.qualys.com/2019/01/09/system-down/system-down.txt it says:
> "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."
> So my assumption was that we didn't need patches for CVE-2018-16865
> since systemd 240 was released in Dec 2018.
We don't need a fix for 16866, but we do need for 16865, right?
--
Bye, Peter Korsgaard
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Buildroot] [PATCH 1/1] package/systemd: add upstream fix for CVE-2018-16864
2019-01-11 11:34 ` Peter Korsgaard
@ 2019-01-11 11:36 ` James Hilliard
2019-01-11 11:45 ` Peter Korsgaard
0 siblings, 1 reply; 9+ messages in thread
From: James Hilliard @ 2019-01-11 11:36 UTC (permalink / raw)
To: buildroot
On Fri, Jan 11, 2019 at 4:34 AM Peter Korsgaard <peter@korsgaard.com> wrote:
>
> >>>>> "James" == James Hilliard <james.hilliard1@gmail.com> writes:
>
> Hi,
>
> >> > +[james.hilliard1 at gmail.com: backport from upstream commit
> >> > +084eeb865ca63887098e0945fb4e93c852b91b0f]
> >> > +Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
> >>
> >> The "standard way" to backport is to use git cherry-pick -sx which adds
> >> a line like:
> > Patch format in buildroot seems to be fairly inconstant. I think this
> > format was what I was recommended to use last.
>
> True. As systemd is maintained in git, it IMHO makes sense to use the
> normal git format.
>
> >> What about CVE-2018-16865, E.G. commit 052c57f132f04a / ef4d6abe7c7fa?
> >> Do those not apply to 240?
> > So here https://www.qualys.com/2019/01/09/system-down/system-down.txt it says:
> > "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."
> > So my assumption was that we didn't need patches for CVE-2018-16865
> > since systemd 240 was released in Dec 2018.
>
> We don't need a fix for 16866, but we do need for 16865, right?
That is not entirely clear to me as there seems to be contradictory info.
>
> --
> Bye, Peter Korsgaard
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Buildroot] [PATCH 1/1] package/systemd: add upstream fix for CVE-2018-16864
2019-01-11 11:36 ` James Hilliard
@ 2019-01-11 11:45 ` Peter Korsgaard
2019-01-11 11:48 ` James Hilliard
0 siblings, 1 reply; 9+ messages in thread
From: Peter Korsgaard @ 2019-01-11 11:45 UTC (permalink / raw)
To: buildroot
>>>>> "James" == James Hilliard <james.hilliard1@gmail.com> writes:
Hi,
>> >> What about CVE-2018-16865, E.G. commit 052c57f132f04a / ef4d6abe7c7fa?
>> >> Do those not apply to 240?
>> > So here https://www.qualys.com/2019/01/09/system-down/system-down.txt it says:
>> > "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."
>> > So my assumption was that we didn't need patches for CVE-2018-16865
>> > since systemd 240 was released in Dec 2018.
>>
>> We don't need a fix for 16866, but we do need for 16865, right?
> That is not entirely clear to me as there seems to be contradictory info.
Sorry, what is unclear about "CVE-2018-16865 was introduced in December
2011 (systemd v38) and became exploitable in April 2013 (systemd v201)"?
--
Bye, Peter Korsgaard
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Buildroot] [PATCH 1/1] package/systemd: add upstream fix for CVE-2018-16864
2019-01-11 11:45 ` Peter Korsgaard
@ 2019-01-11 11:48 ` James Hilliard
2019-01-11 11:53 ` Peter Korsgaard
0 siblings, 1 reply; 9+ messages in thread
From: James Hilliard @ 2019-01-11 11:48 UTC (permalink / raw)
To: buildroot
On Fri, Jan 11, 2019 at 4:46 AM Peter Korsgaard <peter@korsgaard.com> wrote:
>
> >>>>> "James" == James Hilliard <james.hilliard1@gmail.com> writes:
>
> Hi,
>
> >> >> What about CVE-2018-16865, E.G. commit 052c57f132f04a / ef4d6abe7c7fa?
> >> >> Do those not apply to 240?
> >> > So here https://www.qualys.com/2019/01/09/system-down/system-down.txt it says:
> >> > "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."
> >> > So my assumption was that we didn't need patches for CVE-2018-16865
> >> > since systemd 240 was released in Dec 2018.
> >>
> >> We don't need a fix for 16866, but we do need for 16865, right?
> > That is not entirely clear to me as there seems to be contradictory info.
>
> Sorry, what is unclear about "CVE-2018-16865 was introduced in December
> 2011 (systemd v38) and became exploitable in April 2013 (systemd v201)"?
The part that is unclear is that it supposedly "was inadvertently
fixed in August 2018".
>
> --
> Bye, Peter Korsgaard
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Buildroot] [PATCH 1/1] package/systemd: add upstream fix for CVE-2018-16864
2019-01-11 11:48 ` James Hilliard
@ 2019-01-11 11:53 ` Peter Korsgaard
2019-01-11 12:04 ` James Hilliard
0 siblings, 1 reply; 9+ messages in thread
From: Peter Korsgaard @ 2019-01-11 11:53 UTC (permalink / raw)
To: buildroot
>>>>> "James" == James Hilliard <james.hilliard1@gmail.com> writes:
Hi,
> On Fri, Jan 11, 2019 at 4:46 AM Peter Korsgaard <peter@korsgaard.com> wrote:
>>
>> >>>>> "James" == James Hilliard <james.hilliard1@gmail.com> writes:
>>
>> Hi,
>>
>> >> >> What about CVE-2018-16865, E.G. commit 052c57f132f04a / ef4d6abe7c7fa?
>> >> >> Do those not apply to 240?
>> >> > So here https://www.qualys.com/2019/01/09/system-down/system-down.txt it says:
>> >> > "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."
>> >> > So my assumption was that we didn't need patches for CVE-2018-16865
>> >> > since systemd 240 was released in Dec 2018.
>> >>
>> >> We don't need a fix for 16866, but we do need for 16865, right?
>> > That is not entirely clear to me as there seems to be contradictory info.
>>
>> Sorry, what is unclear about "CVE-2018-16865 was introduced in December
>> 2011 (systemd v38) and became exploitable in April 2013 (systemd v201)"?
> The part that is unclear is that it supposedly "was inadvertently
> fixed in August 2018".
But that refers to 18666 and NOT 18665?
--
Bye, Peter Korsgaard
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Buildroot] [PATCH 1/1] package/systemd: add upstream fix for CVE-2018-16864
2019-01-11 11:53 ` Peter Korsgaard
@ 2019-01-11 12:04 ` James Hilliard
0 siblings, 0 replies; 9+ messages in thread
From: James Hilliard @ 2019-01-11 12:04 UTC (permalink / raw)
To: buildroot
On Fri, Jan 11, 2019 at 4:53 AM Peter Korsgaard <peter@korsgaard.com> wrote:
>
> >>>>> "James" == James Hilliard <james.hilliard1@gmail.com> writes:
>
> Hi,
>
> > On Fri, Jan 11, 2019 at 4:46 AM Peter Korsgaard <peter@korsgaard.com> wrote:
> >>
> >> >>>>> "James" == James Hilliard <james.hilliard1@gmail.com> writes:
> >>
> >> Hi,
> >>
> >> >> >> What about CVE-2018-16865, E.G. commit 052c57f132f04a / ef4d6abe7c7fa?
> >> >> >> Do those not apply to 240?
> >> >> > So here https://www.qualys.com/2019/01/09/system-down/system-down.txt it says:
> >> >> > "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."
> >> >> > So my assumption was that we didn't need patches for CVE-2018-16865
> >> >> > since systemd 240 was released in Dec 2018.
> >> >>
> >> >> We don't need a fix for 16866, but we do need for 16865, right?
> >> > That is not entirely clear to me as there seems to be contradictory info.
> >>
> >> Sorry, what is unclear about "CVE-2018-16865 was introduced in December
> >> 2011 (systemd v38) and became exploitable in April 2013 (systemd v201)"?
> > The part that is unclear is that it supposedly "was inadvertently
> > fixed in August 2018".
>
> But that refers to 18666 and NOT 18665?
Hmm, not sure why I was mixing those up, you're right.
>
> --
> Bye, Peter Korsgaard
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2019-01-11 12:04 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-01-11 7:54 [Buildroot] [PATCH 1/1] package/systemd: add upstream fix for CVE-2018-16864 james.hilliard1 at gmail.com
2019-01-11 10:46 ` Peter Korsgaard
2019-01-11 11:03 ` James Hilliard
2019-01-11 11:34 ` Peter Korsgaard
2019-01-11 11:36 ` James Hilliard
2019-01-11 11:45 ` Peter Korsgaard
2019-01-11 11:48 ` James Hilliard
2019-01-11 11:53 ` Peter Korsgaard
2019-01-11 12:04 ` James Hilliard
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.