Bug#727708: systemd (security) bugs (was: init system question)
Hi Ian,
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
>> CVE summary Debian BTS Redhat
>> 2012-0871 systemd-logind insecure file creation ? 795853
>> 2012-1101 DoS from systemctl status 662029 799902
>> 2012-1174 TOCTOU deletion race in systemd-logind 664364 803358
>> 2013-4327 insecure use of polkit 723713 1006680
>> 2013-4391 systemd journald integer overflow 725357 859051
>> 2013-4392 TOCTOU race updating file perms 725357 859060
>> 2013-4393 systemd journald DoS 725357 859104
>> 2013-4394 improper sanitization of XKB layouts 725357 862324
>
> It isn't always 100% clear to me from reading these which of them
> apply to systemd's init replacement. But reading the systemd debate
2012-1101 does, I think 2013-4327 and 2013-4392 might, all the others do
not affect the init part of src:systemd.
> Furthermore, I think it is fair to look at bugs in non-pid-1 parts of
> the systemd codebase when assessing the likely code quality of the pid
> 1 parts.
I don’t really agree. The code quality of other parts of the systemd
ecosystem sure are related and probably provide a good trend of the
overall code quality. However, there are some “subsystems” of systemd,
which are to a big part written by non-core contributors. Take for
example networkd, a minimal network configuration for static
(server-ish) setups, which was largely implemented by Tom Gundersen:
http://cgit.freedesktop.org/systemd/systemd/log/src/network
Or take journald, which also has plenty of contributors:
http://cgit.freedesktop.org/systemd/systemd/log/src/journal?ofs=50
http://cgit.freedesktop.org/systemd/systemd/log/src/journal?ofs=100
One can compare this to the Linux kernel, I think: looking at any
subsystem will give you a somewhat useful idea about the overall code
quality, but it’s not fair to say linux’s syscall security sucks just
by looking at the filesystem code.
> I should say that it is hard to write code with no security bugs at
> all. But I think our benchmark for security bugs in our init system
> ought to be "very few", particularly if we are making a specific
> implementation effectively mandatory. And I don't think I would like
> to accept justifications (for a large bug count) along the lines of
> "but systemd does so much more"; I think the security bugs that come
> with a large codebase, or having more functionality exposed to
> ordinary users, are a direct and very relevant downside to such a
> large codebase or large attack surface.
They sure are. OTOH, chosing the init system that receives the most
attention in form of development and is adopted by many other
distributions helps us a lot with security issues. They are no longer
just our problem, but other distributions also care about getting them
fixed quickly.
> There are a couple of filesystem races (CVE-2012-1174, CVE-2013-4392)
> which I think a concurrent init system author ought really to be
> competent to avoid. (And the system should be designed, so far as
> possible, to reduce the opportunity for such races.)
“a concurrent init system author” sounds strange on multiple counts:
systemd was not written by one author. It is also not concurrent (in
fact it is single-threaded and only links to pthreads to call sync
asynchronously on shutdown), but event-based. As for competency, I am
sure that everybody involved has learned their lesson and will avoid
such issues in the future. I am also sure that other init systems have
(had) similar bugs. And if there is no evidence of that yet, maybe
nobody looked really closely yet…? :)
> The "systemctl status" resource usage DoS (CVE-2012-1101) is an
> understandable resource leak, given systemd's design. But for me it
> raises this question: why is the system designed in such a way that
> the critical pid 1 is required to implement functionality (and
> unprivileged-facing interfaces) in which such a resource leak is (a) a
> likely programming error and then (b) exposed so as to be exploitable.
a) I think “a likely programming error” is an exaggeration. Do you have
data on how often there were resource leaks in systemd?
b) I am unclear on how exactly this was exploitable, and the bugs lack
explanation unfortunately.
Furthermore, I think Lennart’s explanation of why arbitrary units must
be able to be created is fair:
https://bugzilla.redhat.com/show_bug.cgi?id=680122#c1
> AIUI the journald integer overflow (CVE-2013-4391) is a remotely
> exploitable bug, if you have configured journald to allow remote
> logging. (I assume this isn't the default configuration but haven't
> checked.)
journald does not provide remote logging. See
https://lists.fedoraproject.org/pipermail/devel/2013-July/185585.html
> The other journald one (CVE-2013-4393) seems to stem from a poor
> design decision: journald expects to be given an fd and then reads
> from it. The authors of this obviously-security-critical code failed
> to appreciate the variety of exciting things that can happen to the
> recipient of an fd. I wonder even whether the code change
> http://cgit.freedesktop.org/systemd/systemd/commit/?id=1dfa7e79a60de680086b1d93fcc3629b463f58bd
> which is supposed to fix the bug is sufficient. Even if it does it
> certainly isn't pretty. But also it is concerning that people who
> have decided to make extensive use of advanced features of the Linux
> system call interface apparently aren't aware of important and
> hopefully well-known dangers in facilities such as cross-trust-domain
> fd passing.
Personally, I don’t know about every little detail in fd passing
either. If I read you correctly, you seem to be saying one needs to be
an expert in a given area before being allowed to write code in it. I
think it works the other way around: by writing code in that area, you
become an expert in it.
The general statement from your side here seems to be (exaggerating a
bit for the sake of discussion): “look, this software has bugs, even
security bugs, so let’s not use it”. While I certainly would not want to
switch to an extremely buggy software myself either, I think we all know
that software is never entirely free of bugs. Expecting an absence of
bugs even before starting to use that software certainly is
unrealistic.
Moreover, consider that whole classes of bugs existed before, spread out
in the various init scripts, which are obsolete thanks to systemd’s
design, these two just being trivial examples off the top of my head:
• improperly sanitized environment, see e.g.
https://bugzilla.redhat.com/show_bug.cgi?id=990321
• runaway scripts (e.g. cgi-bin) that spawn children and escape the main
daemon (e.g. apache2) being stopped.
Instead of focusing on the actual security issues, what I’d much rather
look at is the process with which such bugs are fixed. I.e. are security
problems acknowledged as such, are they fixed clearly and in a timely
manner? Are there enough eyes looking at the project to uncover, report
and collaborate in fixing the issues?
Also, and I think that should go without saying, if this branch of the
discussion is considered as reasoning against systemd in the decision
process, I’d like to see similar data on the other init systems :).
Thanks.
--
Best regards,
Michael
Reply to: