42 ms·

Found 51 CVEs relating to systemd since 2012 in a naive search[0]. All software of systemd's complexity has bugs, but a CVE every ~2 months over 7 years isn't h

by KuiN 7y ago

Found 51 CVEs relating to systemd since 2012 in a naive search[0]. All software of systemd's complexity has bugs, but a CVE every ~2 months over 7 years isn't hugely encouraging. Never mind the ever increasing surface area as systemd seems to take on ever increasing amounts responsibility in an average Linux system. I'm absolutely biased and have been unconvinced from day 1, but I've not seen much to dull my scepticism either. [0] https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=systemd https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=systemd

youdontknowtho 7y ago
I'm not trying to troll here but if I replace 'systemd' with 'linux' there are over 5k. The truth about computer security is that it is abismal. Somethings are better than others but complex software written in unsafe languages...unsafe is gonna unsafe.
NelsonMinar 7y ago
I think this kind exposure is inevitable with something as big as systemd. If you look at the old scripts-and-daemons hairball that systemd replaces, it has a lot of security warts too. (Albeit with 20 years of wart removal as well.) What worries me is that systemd is not engineered and managed as a project with this kind of risk. Instead it feels like a lot of cowboy coding.
- qxnqd 7y ago
  SystemD should not be as big as it is.
- zzzcpan 7y ago
  > If you look at the old scripts-and-daemons hairball that systemd replaces, it has a lot of security warts too. Not even close. Scripts were always memory safe and limitations of shell didn't allow to go crazy with things and introduce security issues left and right.
  - dfox 7y ago
    Whether shell is memory-safe is completely irrelevant as the language has more significant safety issues with regards to quoting, eval and such. And second reason why it is irrelevant is that the traditional bunch-of-shell-scripts init system does not process any kind of untrusted input.
    - zzzcpan 7y ago
      It does deal with some untrusted input, often not directly in shell though, but through other tools.
  - bonzini 7y ago
    Instead you had quoting bugs where the shell scripts ended up rm -rf /'ing your machine.
teddyh 7y ago
If you want to find reasons to dislike systemd, you’ll find plenty to pick and choose from. But if you instead want to have systemd, and therefore want to find reasons that it’s worth it, you’ll likewise find lots of those. Whatever your initial opinion, you’ll find plenty of things to support your case. Meta-reasons for wanting to like systemd in the first place include: 1a. It has plenty of nifty new features using the latest Linux features, most prominently cgroups. 2a. It makes it relatively easy to take advantage of those features for your own services, and/or to alter existing services to your liking. 3a. Probably for reasons 1a and 2a, most Linux distributions have long since changed to use systemd, and getting used to using a standard system is useful in real life. The only meta-reasons for not liking systemd which I have seen are: 1b. It doesn’t work the way Unix always worked, and some people don’t like using it, since they don’t know all the ins and outs like they might do with the old systems. 2b. It seems to acquire, subsume and supplant lots of previously separate Unix systems like init, cron, syslog, ifconfig, etc. This, combined with 1b, only exacerbates the pain. All other criticisms that I have seen can be adequately explained as being after-the-fact rationalizations stemming from 1b and 2b. (Note: Anyone still using ifconfig on Linux should get with the program and start using ip(8) already: https://manpages.debian.org/testing/iproute2/ip.8.en.html https://manpages.debian.org/testing/iproute2/ip.8.en.html)
- iso1631 7y ago
  Longevity and stability is a big issue for me. Systemd may be the new way to do things, but will it be doing it the same way in 5 years? I'm not confident it will. iproute has nothing to do with systemd, and I use it a lot (although I prefer the default visibility of "ifconfig" rather than "ip -o a" to see what IPs I have on what interfaces).
  - cycloptic 7y ago
    Systemd does have a wiki page about this: https://www.freedesktop.org/wiki/Software/systemd/InterfaceStabilityPromise/ https://www.freedesktop.org/wiki/Software/systemd/InterfaceS...
- gmueckl 7y ago
zzzcpan 7y ago
While systemd is a significant downgrade in security compared to init systems written in shell, which is memory safe, this particular hole can be attributed to many things, but systemd is barely one of them. Linux networking stack is pretty messy, iptables can barely be called a firewall with awful usability and there is no best practice to use firewall to limit the surface you expose to other things on the network. It doesn't have to be like that. I remember when I used freebsd the first time there was already a suggestion somewhere to block packets with local ip addresses coming into wan interfaces and block, allow packets based on "icmptypes" and "established" flags, and ipfw itself was nice and usable, so it was always a big part of regular practice on freebsd.
- iso1631 7y ago
  > iptables can barely be called a firewall Why?
gameswithgo 7y ago
how many were memory safety as a root cause?
mariusor 7y ago
I've seen this argument raised a couple of times so far on the internet, and when I offer the same search with the keyword "linux" people seem to feel like it's not exactly an apples to apples comparison. So, maybe you can try the search with the name of your favourite project (that maybe is similar in scope and user base to systemd) and tell us what you find? Are the numbers that dissimilar?

by KuiN 7y ago

youdontknowtho 7y ago

I'm not trying to troll here but if I replace 'systemd' with 'linux' there are over 5k. The truth about computer security is that it is abismal. Somethings are better than others but complex software written in unsafe languages...unsafe is gonna unsafe.

NelsonMinar 7y ago

I think this kind exposure is inevitable with something as big as systemd. If you look at the old scripts-and-daemons hairball that systemd replaces, it has a lot of security warts too. (Albeit with 20 years of wart removal as well.) What worries me is that systemd is not engineered and managed as a project with this kind of risk. Instead it feels like a lot of cowboy coding.

qxnqd 7y ago
SystemD should not be as big as it is.
zzzcpan 7y ago
> If you look at the old scripts-and-daemons hairball that systemd replaces, it has a lot of security warts too. Not even close. Scripts were always memory safe and limitations of shell didn't allow to go crazy with things and introduce security issues left and right.
- dfox 7y ago
  Whether shell is memory-safe is completely irrelevant as the language has more significant safety issues with regards to quoting, eval and such. And second reason why it is irrelevant is that the traditional bunch-of-shell-scripts init system does not process any kind of untrusted input.
  - zzzcpan 7y ago
    It does deal with some untrusted input, often not directly in shell though, but through other tools.
- bonzini 7y ago
  Instead you had quoting bugs where the shell scripts ended up rm -rf /'ing your machine.

teddyh 7y ago

If you want to find reasons to dislike systemd, you’ll find plenty to pick and choose from. But if you instead want to have systemd, and therefore want to find reasons that it’s worth it, you’ll likewise find lots of those. Whatever your initial opinion, you’ll find plenty of things to support your case. Meta-reasons for wanting to like systemd in the first place include: 1a. It has plenty of nifty new features using the latest Linux features, most prominently cgroups. 2a. It makes it relatively easy to take advantage of those features for your own services, and/or to alter existing services to your liking. 3a. Probably for reasons 1a and 2a, most Linux distributions have long since changed to use systemd, and getting used to using a standard system is useful in real life. The only meta-reasons for not liking systemd which I have seen are: 1b. It doesn’t work the way Unix always worked, and some people don’t like using it, since they don’t know all the ins and outs like they might do with the old systems. 2b. It seems to acquire, subsume and supplant lots of previously separate Unix systems like init, cron, syslog, ifconfig, etc. This, combined with 1b, only exacerbates the pain. All other criticisms that I have seen can be adequately explained as being after-the-fact rationalizations stemming from 1b and 2b. (Note: Anyone still using ifconfig on Linux should get with the program and start using ip(8) already: https://manpages.debian.org/testing/iproute2/ip.8.en.html https://manpages.debian.org/testing/iproute2/ip.8.en.html)

iso1631 7y ago
Longevity and stability is a big issue for me. Systemd may be the new way to do things, but will it be doing it the same way in 5 years? I'm not confident it will. iproute has nothing to do with systemd, and I use it a lot (although I prefer the default visibility of "ifconfig" rather than "ip -o a" to see what IPs I have on what interfaces).
- cycloptic 7y ago
  Systemd does have a wiki page about this: https://www.freedesktop.org/wiki/Software/systemd/InterfaceStabilityPromise/ https://www.freedesktop.org/wiki/Software/systemd/InterfaceS...
gmueckl 7y ago

zzzcpan 7y ago

While systemd is a significant downgrade in security compared to init systems written in shell, which is memory safe, this particular hole can be attributed to many things, but systemd is barely one of them. Linux networking stack is pretty messy, iptables can barely be called a firewall with awful usability and there is no best practice to use firewall to limit the surface you expose to other things on the network. It doesn't have to be like that. I remember when I used freebsd the first time there was already a suggestion somewhere to block packets with local ip addresses coming into wan interfaces and block, allow packets based on "icmptypes" and "established" flags, and ipfw itself was nice and usable, so it was always a big part of regular practice on freebsd.

iso1631 7y ago
> iptables can barely be called a firewall Why?

gameswithgo 7y ago

how many were memory safety as a root cause?

mariusor 7y ago

I've seen this argument raised a couple of times so far on the internet, and when I offer the same search with the keyword "linux" people seem to feel like it's not exactly an apples to apples comparison. So, maybe you can try the search with the name of your favourite project (that maybe is similar in scope and user base to systemd) and tell us what you find? Are the numbers that dissimilar?