Systemd Opened Security Hole in Linux, VPNs Could Be Compromised | Hacker News Reader

Systemd Opened Security Hole in Linux, VPNs Could Be Compromised

linuxreviews.org

59 pointsChaekyung30 comments

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/lin... for the official documentation for this parameter.

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.

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.

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

> 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.

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.

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

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.

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.

SystemD should not be as big as it is.

> 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.

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.

It does deal with some untrusted input, often not directly in shell though, but through other tools.

Instead you had quoting bugs where the shell scripts ended up rm -rf /'ing your machine.

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)

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).

Systemd does have a wiki page about this:

https://www.freedesktop.org/wiki/Software/systemd/InterfaceS...

You're neglecting one other major reason for disliking systemd:

3b. Not working as advertised.

I have consistently run into major issues on various machines with trivial configurations. I am left with no choice but to ban systemd from all my machines because it's not usable.

I hear you. When I first tried to use systemd-networkd, it didn’t work. Last I tried, I couldn’t get systemd-resolved to work they way I like to configure things. However, systemd itself has mostly worked for me, and I trust (since its use is so common and upstream seems active) it’s only going to get better, and all these problems will be fixed. It’s all in what you personally want to believe in.

You are perfectly justified in avoiding what you see to be problematic software. However, it is mainstream, and bugs seem to be fixed over time. If we assume this to be true, there will come a time when systemd is working perfectly adequately for your needs, but you are completely unprepared to use it, since you haven’t had the training which most everyone else has gotten until then. You see? I have my rationalizations and you have yours.

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.

> iptables can barely be called a firewall

Why?

how many were memory safety as a root cause?

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?

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

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

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).

Did you perhaps mean to say you're not convinced?

Yes, I did a sloppy editing pass over the first sentence. Fixed.

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

> 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.

Reply on news.ycombinator.com