Linux's Systemd can be pwned via an evil DNS query

This is the systemd DNS service that Poettering & co. recommended to use...
https://www.theregister.co.uk/2017/06/29/systemd_pwned_by_dns_query/

Some others considerations about resolvd from Andrew Ayer's blog:
DNS is a complicated, security-sensitive protocol. In August 2014, Lennart Poettering declared that "systemd-resolved is now a pretty complete caching DNS and LLMNR stub resolver." In reality, systemd-resolved failed to implement any of the documented best practices to protect against DNS cache poisoning. It was vulnerable to Dan Kaminsky's cache poisoning attack which was fixed in every other DNS server during a massive coordinated response in 2008 (and which had been fixed in djbdns in 1999). Although systemd doesn't force you to use systemd-resolved, it exposes a non-standard interface over DBUS which they encourage applications to use instead of the standard DNS protocol over port 53. If applications follow this recommendation, it will become impossible to replace systemd-resolved with a more secure DNS resolver, unless that DNS resolver opts to emulate systemd's non-standard DBUS API.
 
I'm just waiting patiently for that whole systemd debacle to massively implode by itself. Seems like it's bound to happen sooner or later.
 
I'm just waiting patiently for that whole systemd debacle to massively implode by itself. Seems like it's bound to happen sooner or later.

I'm hoping for the same thing. I wish I had your insight to see that it is bound to happen. But now we are getting pretty far off-topic.
 
Well, maybe Poettering just recycled his Avahi mDNS? This thing also had at least one nasty RCE vuln. Other parts of the Avahi-bloatwork also had some pretty ugly CVEs and so did pulseaudio - so I guess it runs in the family :rolleyes:

The nice thing about systemd: It never fails to deliver at least one highly amusing "facepalm-moment" each week. E.g. last week it was the DoS by setting an environment Variable: https://github.com/systemd/systemd/issues/6152
Also very high on the scoreboard: A PHP library for managing services: https://github.com/mjanser/php-systemctl (what could possibly go wrong?)

Looking at the cadence of critical bugs and CVEs for the various parts of systemd, it seems meltdown is imminent - so prepare some popcorn and grab a cold beer :cool:
 
Well, maybe Poettering just recycled his Avahi mDNS? This thing also had at least one nasty RCE vuln. Other parts of the Avahi-bloatwork also had some pretty ugly CVEs and so did pulseaudio - so I guess it runs in the family :rolleyes:

The nice thing about systemd: It never fails to deliver at least one highly amusing "facepalm-moment" each week. E.g. last week it was the DoS by setting an environment Variable: https://github.com/systemd/systemd/issues/6152
Also very high on the scoreboard: A PHP library for managing services: https://github.com/mjanser/php-systemctl (what could possibly go wrong?)

Looking at the cadence of critical bugs and CVEs for the various parts of systemd, it seems meltdown is imminent - so prepare some popcorn and grab a cold beer :cool:

the most fascinating thing about Linux is that it proves that most Linux distros do not have any possible interests in preserving Unix like systems and following Unix philosophy.
+ Linux does takes whatever looks modern and cool, without caring at all if it can be stable or not.
 
I'm just waiting patiently for that whole systemd debacle to massively implode by itself. Seems like it's bound to happen sooner or later.

It probably will at some point, but not before adding "sytemd-desktopd" and "systemd-kerneld" to make the Poettering ecosystem complete and eliminate any resemblance with Unix. :rolleyes:

Anyway, as support for non-systemd Linux distros runs out, I will deploy more FreeBSD and Manjaro OpenRC (on notebooks) installations.
 
I'm just waiting patiently for that whole systemd debacle to massively implode by itself. Seems like it's bound to happen sooner or later.
Possible. I had the misfortune to have to use systemd on very large IO servers (the kind of machine which has every PCI slot stuffed with either SAS or Infiniband cards, and connects to many hundreds of disks). It was very amusing. You need an angel-like patience and a good sense of humor to live with a systemd-based system.

On the other hand: The Linux ecosystem (which contains many large companies, such as IBM and RedHat) has enough people, they can get anything to work. My prediction is different from yours: I don't think Linux with systemd will implode; instead it will become weirder and weirder, and be kept working with more and more (software-) duct tape and shoestring, until it becomes something like Windows: Impenetrable, weird, illogical, but actually functions. But at that point, any logical structure and simplicity will be gone.

The problem with Linux is that there is no technical authority any longer, who can shout "uncle" when the pain gets to be too great. It is out of control, in the literal sense of the words.
 
Not to worry though, I'm sure they'll soon add firewall functionality into systemd, something which the Linux masses have no doubt long waited for :D
 
quite enlightening reading
https://lists.dns-oarc.net/pipermail/dns-operations/2016-June/014964.html

Code:
- It uses nsswitch to basically take over gethostbyname*() and
   getaddrinfo(). This means any software using a DNS library like ldns,
    unbound, bind, knot, etc bypasses this system and gets an inconsistent
    DNS view from the rest of the system. It explictely does not support
    those kind of applications. Due to its issues below, this is a problem
    for applications insisting on DNSSEC answers (eg postfix). It does not
    supply a "local DNS server" that those dns libraries could use to get
    a consistent view.

- it fudges with /etc/resolv.conf, but it does not provide a DNS server.
    So it cannot put 127.0.0.1 in resolv.conf. This means ANY application
    using /etc/resolv.conf that does not use glibc is going to go around
    systemd-resolvd. Yet systemd-resolvd messes with resolv.conf.

- The process turns a request for binary DNS data into into XML, feeds it
    into the sytemd/dus ecosystem, which turns it into binary DNS to send
    it to the forwarder. The binary DNS answer then gets turned into XML
    goes through systemd/dbus, then is turned back into binary DNS to feed
    back into glibc. Apart from errors in this process, like last year's
    CVE on cache poisoning attacks, this means the systemd people need to
    very actively maintain their code whenever a new feature or RRTYPE is
    added to the DNS protocol. Maintenance and bugfixes is not systemd's
    strong point. This architecture is overly complex and unneccessary.

- It won't work well with applications that have their own DNS code
    itside. Such as browsers. This becomes worse when you think about
    browsers supporting draft-shore-tls-dnssec-chain-extension.

- It is yet another program/daemon that runs races with other software
    in controlling /etc/resolv.conf. Eg VPN software adding nameservers.

- There is no option to become a full recursive DNS server. It depends
    on a forwarder being obtained via DHCP. This means any broken
    forwarder leads to a broken setup. eg an upstream that strips DNSSEC.

- It accepts DNS forwarders for all its interfaces. That means if you
    are on wifi and 3g, or ethernet and wifi, you have more than one
    DNS server from logically different networks. With no way of
    guaranteeing which logical network you asking.

- It sends out a DNS queries over all its obtained DNS servers all the
    time. This means DNS queries for split-DNS view resources leak all
    over the internet.

- It accepts the first valid answer. This could be an unsigned answer.
    This means a local attacker (eg wifi hotspot) has an advantage over
    the actual real DNS forwarders.

- It prefers an answer over an NXDOMAIN as workaround for the above.
    So if some A record does not exist, the NXDOMAIN is ignored in
    favour of a forged, or rogue wildcard type, answer.

- It does not implement RFC-5011 properly. It might remove trusted keys
    upon seeing the revoke bit instead of waiting the time period
    specified in RFC-5011.

- I believe it does not support DNS-over-TLS

- I _believe_ it does not support network changes that requre a cache
    flush, for instance a VPN network with an internal *.corp.company.com
    whose entries need to be removed from the cache when the network is
    lost.

- I _believe_ it does not handle trust anchors linked to DNS nameserver
    IP addreses. Needed for DHCP servers relaying multiple domain names
    for resolving and VPN situations like draft-pauly-ipsecme-split-dns-01

- I _believe_ it will not able to reconfigure forwarders on the fly.
 
the most fascinating thing about Linux is that it proves that most Linux distros do not have any possible interests in preserving Unix like systems and following Unix philosophy.
Not that RMS governs GNU/Linux, but he's said he was "never a supporter of the Unix design philosophy" (via reddit: https://www.reddit.com/r/linux/comments/63mo8p/rms_on_systemd_and_the_unix_philosophy/ ), given his influence I'm not surprised that the wider Linux world doesn't care about it...
 
That moment when you lose even more faith in humanity :confused:

At moments like these I'm really happy that I discovered FreeBSD several years ago. Linux is most definitely going into the same directions as Windows it seems when it comes to bizarre and unneeded changes to the system. I can somewhat understand this for Windows (change = new = potential selling point), also because most changes happen in the GUI and not so much the underlying admin tools (msc.exe anyone?).

But Linux is (or was?) mostly targeted at sysadmins to begin with :rolleyes:
 
That moment when you lose even more faith in humanity :confused:
Fortunately, there are still Linux distros that don't use systemd. Unfortunately, in the enterprise and server space (with good paid support), there is no way around RHEL (and SUSE to a lesser extent).

But Linux is (or was?) mostly targeted at sysadmins to begin with :rolleyes:
Initially, it wasn't targeted at anything. It was a bunch of college students that wanted to play with computers, and the i386 made serious Unix-like playing possible. Since the 80s, we had all been dreaming of bringing up full 32-bit machines with virtual memory and demand paging, but the problem was that one couldn't get an unencumbered source tree. Minix sort of fixed that, but it was way too small, a toy system intended for academic instruction, not use.

At that time (late 80s, early 90s), the i386 for the first time brought inexpensive compute power with sufficient memory addressing to the masses. Before that, running serious software was expensive, because it needed expensive hardware (mainframes, VAXes, Sun, HP and IBM RISC machines), and the 68K and 32x32 based systems never became mainstream and affordable (with the exception of the Mac, but that was a closed system). Through the magic combination of DOS/Windows and Intel/AMD, in the early 90s there was suddenly compute power at a price point that really opened it to lots more people and applications: You could get a 32-bit machine with a MMU, multiple MB of memory, and a video card that enabled a GUI, for about $1000 to $2000. That caused a giant vacuum of inexpensive operating systems that could get serious work done on x86 machines, without the hassle and cost of licensing and having to pay support (both for hobbyists, and for commercial low-end use).

Linux filled that void. In those days, Linus was a fun and approachable person (I remember going to drink beer with him at "99 bottles of beer" in Santa Cruz a few times, long before he was married or moved to the US permanently), and a large army of people quickly built the infrastructure around his kernel that was necessary to build production systems (making distributions, setting up FTP servers, porting software, getting XWindows to work, and moving useful software to it). I remember the days when we first ported Fortran codes to it (initially using f2c), and ran X-based data analysis tools such as PAW, on a machine that cost less than a car.

The competition was on the commercial end system 5, but getting a license for it was punishingly difficult and expensive. In the BSD space, there was BSDI (which wasn't free, but very affordable, and the people who handled support contracts were friendly, unlike the SysV vendors). Then Bill and Lynn Jolitz completed 386BSD without using the AT&T encumbered pieces; but that was "too little too late", held back by a variety of factors: Linux was already succeeding, the Jolitz'es were famously obnoxious, the BSD core team was still in the Berkeley ivory tower (and not interested in x86 ports and at war with the Jolitz'es), and there were various lawsuits that kept all *BSD operating systems were under a legal cloud. In my view, *BSD didn't became a viable "competitor" until the early 2000s, by which point Linux had won the free operating system war (saying "competitor" is funny, given that until the rise of the RedHat business model neither made money, and that they actually more complement each other than compete).

But what is definitely true is that Linux, as usually distributed today, has gone down the path Windows blazed in the 90s and 2000s with NT: It's very complex, it's very black box, hard to manage and understand. The only difference is that you can run it without paying anyone; although in practice, if you want to use it in (commercial) production, you will need a support contract unless you are a superhero, because it is too complex to just work. From this viewpoint, systemd is exactly what the commercial Linux support ecosystem needs: it makes it more bizarre and complex, meaning that paid support becomes even more important. Note that Poettering's employer is also the largest vendor of Linux support.
 
It's probably a self-signed certificate without a third party ensuring there are no imitators acting as either party. Or, that happens whenever going to an https site that's not even set up. If that's the case, they did not set up their .htaccess file to redirect from https to http.

I think a lot of Linux and GNU does is good, but relying too heavily on GPL causes inefficiency. It's good, for when a few organizations are using GPL, but when those projects get too big, it just draws clutter when people don't want to give up their work to make it better, benefiting mainly the owning parties of that code.

I found Systemd archaic when I tried using it. It's set up as: what do you want to start on runlevel 1, to runlevel 3 or 5? I just want it to start.
 
My server runs flawlessly well running FreeBSD, it is clean, stable and I feel in security. :)

THIS is exactly why I completely migrated our whole infrastructure and all servers to FreeBSD. No surprises, no weird behaviour - set it up and forget it; it just works.


BTW:
I think I know why linux had to get rid of sysVinit - it had a critical CVE in 1999:
https://nvd.nist.gov/vuln/search/st...ype=statistics&search_type=all&query=sysvinit

Oh wait.... nevermind :rolleyes:
https://nvd.nist.gov/vuln/search/st...&pub_date_end_month=11&pub_date_end_year=2017
 
Back
Top