
Systemd Opened Security Hole in Linux, VPNs Could Be Compromised - Chaekyung
https://linuxreviews.org/Systemd_Opened_Security_Hole_In_Linux,_VPNs_Could_Be_Compromised
======
cesarb
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...](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/networking/ip-
sysctl.txt?h=v5.4#n1225) for the official documentation for this parameter.

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

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

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

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

~~~
teddyh
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
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
Systemd does have a wiki page about this:

[https://www.freedesktop.org/wiki/Software/systemd/InterfaceS...](https://www.freedesktop.org/wiki/Software/systemd/InterfaceStabilityPromise/)

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

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

------
gmueckl
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
Did you perhaps mean to say you're _not_ convinced?

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

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

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

