6 ms·

Systemd Opened Security Hole in Linux, VPNs Could Be Compromised

59 points by Chaekyung 7y ago

shrubble 7y ago
Is anyone surprised? Systemd has been steadily increasing its surface area over the years.
- spacepinball 7y ago
  > Is anyone surprised? It's hardly suprising that opponents like yourself dont even bother to read up on the issue being discussed. Turns out (suprise!?) that the linux defaults in this case is even worse than what systemd provides.
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?
falcolas 7y ago
The title is a bit hyperbolic, but the discussion on the page is a good one. The threat is more academic than having practical exploits in the wild. That said, there have been a lot of “academic” exploits turned into full exploits in the recent years.
gmueckl 7y ago
I am not quite convinced by the arguments with which the attack is downplayed here. I think this explanation is biased too much towards attackimg short lived HTTP connections. Not all TCP connections are short lived. It might also be possible to spoof DNS replies with some guessing (if the VPN endpoint is associated with a known public provider, the DNS server is likely known as well).
- noobermin 7y ago
  Did you perhaps mean to say you're not convinced?
  - gmueckl 7y ago
    Yes, I did a sloppy editing pass over the first sentence. Fixed.
PlutoIsAPlanet 7y ago
So this is just a configuration issue and the kernel defaults to even worse security.
pkilgore 7y ago
A response to the report [1] noted: > This attack works regardless of if you have a VPN or not. The attacker just needs to be able to send packets to the other host. It's not systemd specific. [1] https://seclists.org/oss-sec/2019/q4/123 https://seclists.org/oss-sec/2019/q4/123
- chapium 7y ago
  > Most of the Linux distributions we tested were vulnerable, especially Linux distributions that use a version of systemd pulled after November 28th of last year which turned reverse path filtering off. However, we recently discovered that the attack also works against IPv6, so turning reverse path filtering on isn't a reasonable solution, but this was how we discovered that the attack worked on Linux.
deleted 7y ago
[deleted]
chapium 7y ago
Here is the source (without memes) https://seclists.org/oss-sec/2019/q4/122 https://seclists.org/oss-sec/2019/q4/122
deleted 7y ago
[deleted]
cesarb 7y ago
This title is the opposite of reality. The kernel default for rp_filter is 0, which is disabled. For a long while, systemd had been closing this security hole, by setting it by default to 1 (enabled in strict mode). The recent change in systemd was to change it by default to 2 (enabled in loose mode), which is still stricter than the kernel default of "disabled". See https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/networking/ip-sysctl.txt?h=v5.4#n1225 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... for the official documentation for this parameter.
- MertsA 7y ago
  Not to mention the CVE explicitly states that Devuan and the BSDs as well as a number of other non-systemd distros are affected. Looking closer the submitter here is the author of the post, the website it was submitted to is blocked from being submitted to /r/Linux for blogspam and the "Gangnam Style" links on the page appear to go to some shifty video site. The submitter and author is clearly just writing B.S. to drum up backlinks for some black hat SEO.
- bonzini 7y ago
  Also instructive is the commit message: > The Strict mode breaks some pretty common and reasonable use cases, such as keeping connections via one default route alive after another one appears (e.g. plugging an Ethernet cable when connected via Wi-Fi). > The strict filter also makes it impossible for NetworkManager to do connectivity check on a newly arriving default route (it starts with a higher metric and is bumped lower if there's connectivity). And it goes on pointing out what you also mentioned about kernel defaults: > Kernel's default is 0 (no filter), but a Loose filter is good enough. The few use cases where a Strict mode could make sense can easily override this.

59 points by Chaekyung 7y ago

shrubble 7y ago

Is anyone surprised? Systemd has been steadily increasing its surface area over the years.

spacepinball 7y ago
> Is anyone surprised? It's hardly suprising that opponents like yourself dont even bother to read up on the issue being discussed. Turns out (suprise!?) that the linux defaults in this case is even worse than what systemd provides.

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?

falcolas 7y ago

The title is a bit hyperbolic, but the discussion on the page is a good one. The threat is more academic than having practical exploits in the wild. That said, there have been a lot of “academic” exploits turned into full exploits in the recent years.

gmueckl 7y ago

I am not quite convinced by the arguments with which the attack is downplayed here. I think this explanation is biased too much towards attackimg short lived HTTP connections. Not all TCP connections are short lived. It might also be possible to spoof DNS replies with some guessing (if the VPN endpoint is associated with a known public provider, the DNS server is likely known as well).

noobermin 7y ago
Did you perhaps mean to say you're not convinced?
- gmueckl 7y ago
  Yes, I did a sloppy editing pass over the first sentence. Fixed.

PlutoIsAPlanet 7y ago

So this is just a configuration issue and the kernel defaults to even worse security.

pkilgore 7y ago

A response to the report [1] noted: > This attack works regardless of if you have a VPN or not. The attacker just needs to be able to send packets to the other host. It's not systemd specific. [1] https://seclists.org/oss-sec/2019/q4/123 https://seclists.org/oss-sec/2019/q4/123

chapium 7y ago
> Most of the Linux distributions we tested were vulnerable, especially Linux distributions that use a version of systemd pulled after November 28th of last year which turned reverse path filtering off. However, we recently discovered that the attack also works against IPv6, so turning reverse path filtering on isn't a reasonable solution, but this was how we discovered that the attack worked on Linux.

deleted 7y ago

[deleted]

chapium 7y ago

Here is the source (without memes) https://seclists.org/oss-sec/2019/q4/122 https://seclists.org/oss-sec/2019/q4/122

deleted 7y ago

[deleted]

cesarb 7y ago

This title is the opposite of reality. The kernel default for rp_filter is 0, which is disabled. For a long while, systemd had been closing this security hole, by setting it by default to 1 (enabled in strict mode). The recent change in systemd was to change it by default to 2 (enabled in loose mode), which is still stricter than the kernel default of "disabled". See https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/networking/ip-sysctl.txt?h=v5.4#n1225 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... for the official documentation for this parameter.

MertsA 7y ago
Not to mention the CVE explicitly states that Devuan and the BSDs as well as a number of other non-systemd distros are affected. Looking closer the submitter here is the author of the post, the website it was submitted to is blocked from being submitted to /r/Linux for blogspam and the "Gangnam Style" links on the page appear to go to some shifty video site. The submitter and author is clearly just writing B.S. to drum up backlinks for some black hat SEO.
bonzini 7y ago
Also instructive is the commit message: > The Strict mode breaks some pretty common and reasonable use cases, such as keeping connections via one default route alive after another one appears (e.g. plugging an Ethernet cable when connected via Wi-Fi). > The strict filter also makes it impossible for NetworkManager to do connectivity check on a newly arriving default route (it starts with a higher metric and is bumped lower if there's connectivity). And it goes on pointing out what you also mentioned about kernel defaults: > Kernel's default is 0 (no filter), but a Loose filter is good enough. The few use cases where a Strict mode could make sense can easily override this.