Bug#727708: init system question before the technical committee
On Wed, 27 Nov 2013 19:50:54 + Steven Chamberlain ste...@pyro.eu.org wrote: The sysvinit page doesn't have a specific maintainer/advocate. It is a collection of opinions from discussion on debian-devel@ and elsewhere. Other camps have already responded to parts they don't agree with. Unless any volunteers want to make last-minute small changes, it can probably be taken as 'complete' as soon the tech-ctte is ready to move forward with this. I think maintainers of all the other proposals have said they are ready now. Thanks, Regards, There were elements in form of conversation, and I have made some changes, but didn't want to erase what other people wrote, so now there more elements in form of conversation. Should they be merged (calculate resultant)? signature.asc Description: PGP signature
Bug#727708: systemd (security) bugs (was: init system question)
A friend of mine mentioned to me in the pub that he had seem alarming reports of systemd security bugs. Naturally I asked for more information and he promised me an email with some references. So, here's what Andrew sent me. Thanks to Andrew for doing this legwork. I'll reply substantively in a moment. ---BeginMessage--- Hi Ian, Here's the email about systemd security holes that I kept forgetting to send you. I hope it's (still) useful. The debian-devel post I was thinking of is 441543.92540...@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 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 DoS725357 859104 2013-4394 improper sanitization of XKB layouts725357 862324 I think the really bad one to do with remote connection the guy on debian-devel was thinking of is CVE-2013-4391 which mentions possible arbitrary code execution from a specially crafted packet but I'm not sure under what conditions it would be triggerable over IP, I guess you might have had to set up your system as a remote journald server. 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. 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 Hope this helps, Andrew ---End Message---
Bug#727708: systemd (security) bugs (was: init system question)
Andrew Kanaber akana...@chiark.greenend.org.uk: The debian-devel post I was thinking of is 441543.92540...@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 DoS725357 859104 2013-4394 improper sanitization of XKB layouts725357 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
Bug#727708: systemd (security) bugs (was: init system question)
Ian Jackson wrote: 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. Yes, the other tools that systemd provides and enables are part of its usefulness, so it is appropriate to look into their quality. 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. But this, I think, is completely wrong. You shouldn't count bugs from other tools included with systemd against its core init functionality or vice versa. If for example systemd and coreutils came from the same source package, that should be allowed as many bugs as the current two separate source packages, not less. Most of the separate functionality is optional. It's likely that Debian would want to use it, but then Debian would want that functionality with other init systems too (or miss it). The most appropriate comparison is whether it's possible to have similar functionality with less bugs (whether provided with init system or completely independently). As far as I can see, for most functionality there are no such alternatives. At least Upstart, and likely other alternatives to systemd also, would still use forked versions of at least logind and possibly other tools originating from systemd. Such forks are worse for security than using the original systemd one. Thus the fact that logind is developed with systemd should count in favor of systemd, not against it. Also, systemd is the system under the most intense scrutiny for security and other issues, so it's not easy to compare bug counts with alternatives - alternatives likely have a significantly larger portion of issues undetected. Here are a couple of exciting snippets: 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 I think it's completely obvious that there is no fundamental problem. I wonder what could make you consider it a possible symptom of one. missing feature or perhaps even wrong default configuration. But the bug has been open for some time. My guess is that most people do not consider that exciting or really care - thinking of system states in terms of runlevels is mostly obsolete, and the flaws do not bother many people in the cases where backwards compatibility is still needed. -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1385668823.13584.28.camel@glyph.nonexistent.invalid
Bug#727708: systemd (security) bugs (was: init system question)
Hi Ian, Ian Jackson ijack...@chiark.greenend.org.uk writes: CVE summary Debian BTS Redhat 2012-0871systemd-logind insecure file creation ? 795853 2012-1101DoS from systemctl status 662029 799902 2012-1174TOCTOU deletion race in systemd-logind 664364 803358 2013-4327insecure use of polkit 723713 1006680 2013-4391systemd journald integer overflow 725357 859051 2013-4392TOCTOU race updating file perms 725357 859060 2013-4393systemd journald DoS725357 859104 2013-4394improper sanitization of XKB layouts725357 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
Bug#727708: systemd (security) bugs (was: init system question)
On Thu, Nov 28, 2013 at 11:15:09PM +0100, Michael Stapelberg wrote: 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. All distributions care about not having security issues in their code, but that's not the same thing as actually doing the work to audit the code. In practice this only happens when dedicated resources are turned on the code in question, and having more companies using the code does not magically make that happen. I don't know that the upstart code has been subjected to any sort of comprehensive security audit. I also don't know whether the auditing that's been done on systemd qualifies as comprehensive. I *will* assert that upstart development is aimed at avoiding extraneous features precisely to reduce the risk of bugs (security or otherwise). 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. Are the systemd developers novice programmers, that they need to learn to program securely by trial and error? The reality is that the kind of security bugs that we're talking about are very subtle, and even experienced developers are going to make mistakes like this from time to time, and as one of the arguments advanced for systemd is that it has a large community of contributors, not all of those contributors are going to be experienced developers. A project's security record has at least as much to do with having a solid design to reduce the attack surface, as it does with the developers' skill. 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…? :) Unless you're offering to do a security audit of upstart, I don't think such speculation changes anything. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
