Bug#727708: systemd (security) bugs (was: init system question)
Andrew Kanaber <akanaber@chiark.greenend.org.uk>:
> The debian-devel post I was thinking of is <441543.92540.bm@smtp118.mail.ir2.yahoo.com>
> but it actually only mentions three vulnerabilities, there's a more complete
> list of the ones that have affected Debian at
> https://security-tracker.debian.org/tracker/source-package/systemd
In summary, I agree with Andrew Kanaber's view that the security and
bug history of systemd is worrying.
> Here's a short summary along with the redhat bug numbers (since the
> redhat BTS seems to be the place to go for systemd information)
>
> 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
page makes it clear that the other components in the systemd upstream
package are seen by systemd proponents as part of their offering, and
indeed reasons to pick systemd. Integration between the different
parts of the systemd package is touted as an advantage. For example,
journald is mentioned in the 2nd bullet point under Functionality. So
I think it it is sensible to look at security or other significant
bugs, even in those other systemd components.
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 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.
I went and looked at the security bugs Andrew lists:
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.)
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.
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.)
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.
The XKB one (CVE-2013-4394) is concerning too. I can't quite tell
exactly in what configurations you would be vulnerable, but the bug
itself is not reassuring as regards the authors' additude to
cross-trust-boundary data processing. It looks like there's a bunch
of filenames which are taken from the untrusted side and just
textually stuffed into the X server configuration. Even after the
change which is supposed to fix it,
http://cgit.freedesktop.org/systemd/systemd/commit/?id=0b507b17a760b21e33fc52ff377db6aa5086c6800
it looks like the system might still accept editor backup,
auto-save files, and the like - the filename patterns which are
accepted seem far too generous. I wonder if the authors know whether
whether they are exposing the X server to malicious XKB data.
On to non-security bugs:
Andrew again:
> The bug I mentioned one where bad data in its binary log files causes journald
> to go mad and eventially fill up /var with junk is
> https://bugzilla.redhat.com/show_bug.cgi?id=974132
> and is apparently still not fixed.
I read this and some of the links from it. This is indeed concerning.
Mostly my reaction is "why on earth is this all so complicated?"
> Generally the RedHat BTS at
> https://bugzilla.redhat.com/buglist.cgi?quicksearch=Component:systemd
> and
> https://bugzilla.redhat.com/buglist.cgi?quicksearch=Component:systemd+Status:CLOSED
> make alarming reading
I agree with this sentiment. I just looked at a few of these.
Here are a couple of exciting snippets:
https://bugzilla.redhat.com/show_bug.cgi?id=693605#c1
systemd invents ENOEXEC, resulting in a genuine error due to cycles
in the dependency graph being reported as "Exec format error" (!)
In April 2011 a commenter suggests using EINVAL instead but the
bug unaccountably remains open.
https://bugzilla.redhat.com/show_bug.cgi?id=708537
Problems with runlevel emulation doing mad things. It isn't clear
to me whether this bug is a symptom of a fundamental problem with
systemd's state-based dependency model, or whether it's simply a
missing feature or perhaps even wrong default configuration. But
the bug has been open for some time.
Ian.
Reply to: