The most dangerous thing about systemd-resolved is that it exposes its own non-standard DNS resolution protocol over dbus, which the documentation recommends applications use instead of standard, interoperable protocols[1]:
> The native, fully-featured API systemd-resolved exposes on the bus. See the API Documentation for details. Usage of this API is generally recommended to clients as it is asynchronous and fully featured (for example, properly returns DNSSEC validation status and interface scope for addresses as necessary for supporting link-local networking).
systemd wants applications to depend on systemd-resolved so it becomes irreplaceable. This is very bad, because the first thing you should do on a system with systemd-resolved is uninstall it. The systemd developers are not qualified to write either DNS software[2] or C code that talks to the network.
[2] See http://seclists.org/oss-sec/2014/q4/592, which came out after Lennart Poettering had the hubris to call systemd-resolved a "pretty complete caching DNS and LLMNR stub resolver"[3] even though the dangers of DNS cache poisoning were already well known at the time.
> This is very bad, because the first thing you should do on a system with systemd-resolved is uninstall it.
Thanks, I just realized that my Arch installation has nih-emd-resolved enabled as the default backend for glibc getaddrinfo and friends. This is how it happens:
Does anyone have any insight as to why systemd has its own DNS resolution API? That seems like a very strange decision. Is it really only so that systemd "becomes irreplaceable"?
> systemd-resolved could be made to crash or run programs if it received a specially crafted DNS response.
As nation states are hording zero days, and the security sheep herd insists updates are the way to go, I have never been more convinced that sticking to an OLD AND TRUSTED source code base for your infrastructure is the way to go. You can pop layers on top of that to get newer software running if you like, but trying to keep up with this psuedo-rolling-release avalanche of crap coming down the pipe is not a fair burden for administrators to handle. The devs need to shove it because we don't want it. I am hoping the next economic recession starves out the enthusiasm for disposable infrastructure and "move fast and break things" and businesses can go back to focusing on long term stability.
Is anyone else fed up of systemd yet? Increasingly Jack of all trades, master of none. Can we have something new instead? Or maybe Red Hat can put Pottering back in his holster?
I'm sick of Linux Servers I use, being "improved" with Desktop implementation in mind.
Yes. I've burned hours on systemd related problems that just didn't exist before. From DBus message delivery failures, debugging things that haven't broken for 20 years (which has incidentally got MUCH harder) to the whole shit crock that is NTP and locale management. That and the whole desktop buggery that has been going on for the best part of 8 years now has really put me off. To be honest you haven't really experienced systemd's fuckery until you have a hosed box. It's like negotiating a boot with a pigeon. Any other platform is ZERO hassle and that includes windows, OSX, freebsd, openbsd etc.
And you can't criticise it anywhere (watch the downvotes).
The problem is it lacks the mysterious as in Zen and the Art of Motorcycle Maintenance class "quality". Merely glitter around a turd.
However we're stuck with it so it's suck it up or move on.
On the subject of moving on, you could run FreeBSD to run your servers. Much lower resource overheads, native ZFS, simple service management, some documentation worth more than toilet paper and the best thing of all, more sleep at night. Now there are binary updates and packages it's pretty easy. No more make world of any of that stuff.
I've been against systemd since day 1, because implementation issues aside, the entire concept is flawed and totally against UNIX philosophy: do one thing and do it well. UNIX, and by extension Linux, succeeded because of this philosophy.
It's also fairly transparent that RedHat would like Linux to be more obfuscated so that more enterprises will have to depend on it for support. But that's no surprise. What was surprising was that the Debian foundation not only opted to adopt systemd, but did so long before it was anywhere near proven to be stable, reliable code. This is contrary to their longstanding methodology. Ubuntu's adoption of systemd was simply the result of following Debian upstream. If only enough people could organize Debian to reverse course on systemd, if only until systemd proves to be stable and reliable (likely never). However, let's not pretend this is the first time that Linux has deviated from traditional UNIX and compatibility. There's always been Linuxisms, systemd is just by far the most egregious case.
FreeBSD has really come of age with pkgng though, and I'm happy to see it garner more attention now due to systemd woes. It has always excelled in certain ways, which is why Whatsapp was able to scale to millions of connections on a single box way back in 2012, its process/thread scheduling resulting in more responsiveness under load, better packet filtering, containerization much earlier on (jails), native ZFS, etc.
The answer is to leave the mainstream linux ecosystem, sadly. Slackware has been good to me. Openbsd is nice. Rolling your own userland is as possible as it's ever been. Maybe it's time to leave.
But does not the FreeBSD project even more focus on memory unsafe languages (C) and is more monolithic then Linux distribution in general (userspace must match kernel).
That is not what springs to mind, more "why the fuck are you reimplementing DNS in init".
Like, this stuff was built tens of years ago and that code is crappy too but we have pretty much got rid of the most obvious security issues. Nobody wants to relive history so you can finally implement a broken DNS client.
How plausible is it that someone/some group could rewrite/update this to be written in Rust? (Which would presumably solve a lot of the memory corruption issues if I understand Rust's memory safety correctly?).
It only affect ubuntu's way of systemd that is discouraged by systemd's community
Some one called a title another systemd's vulnerability a click biat
Quote
Try to guess what title catches more clicks:
1. CVE-2017-9445: systemd Hit By New Security Vulnerability
2. CVE-2017-9445: systemd-resolved, which is not recommended on most systems and isn't used outside of Ubuntu Hit By New Security Vulnerability
Looks like you need to make a DNS request to a malicious server to be vulnerable. This means you are safe if you are using 8.8.8.8? Or another trusted network? (Or your ISP if you trust they haven't been compromised).
The real danger is a script kiddie on your LAN with a sniffer or some advanced attacker in the position to MITM you on the wide Internet, depending on whether you are a small fish or a big fish.
US corporations control the root name servers and seem to have no problem cooperating with government requests to fuck^H^H^H^Hkeep a close eye on everyone else.
It's extremely easy to induce a computer to make a DNS request. For example, embed an IMG tag in a web page pointing to the attacker's domain. Anyone loading that page will get the malicious DNS response.
The title is slightly misleading since it is specifically the optional (but installed by default on Ubuntu) systemd-resolved package (an ancillary package under the systemd name), not systemd the init system as I think many people will assume.
Edit: It seems Ubuntu builds it together with systemd so users have no choice. There may be a good technical reason for this, but I'm not sure what it is because it seems very user-hostile to remove choice like this.
Edit2: Upon further inspection this appears to be common practice, you just don't enable the parts you don't want. It would be nice if they could be put into separate packages or something of that nature though.
Well no not really. Vulnerabilities exist outside the realms of the language implementations. There are poorly designed protocols and access controls to contend with as well. I'd argue there are a lot more of those classes of problems out there. The ones enabled by programming languages are merely easier to find as you don't have to understand the precise problem domain of the application for each one found.
[+] [-] agwa|8 years ago|reply
> The native, fully-featured API systemd-resolved exposes on the bus. See the API Documentation for details. Usage of this API is generally recommended to clients as it is asynchronous and fully featured (for example, properly returns DNSSEC validation status and interface scope for addresses as necessary for supporting link-local networking).
systemd wants applications to depend on systemd-resolved so it becomes irreplaceable. This is very bad, because the first thing you should do on a system with systemd-resolved is uninstall it. The systemd developers are not qualified to write either DNS software[2] or C code that talks to the network.
[1] https://www.freedesktop.org/software/systemd/man/systemd-res...
[2] See http://seclists.org/oss-sec/2014/q4/592, which came out after Lennart Poettering had the hubris to call systemd-resolved a "pretty complete caching DNS and LLMNR stub resolver"[3] even though the dangers of DNS cache poisoning were already well known at the time.
[3] https://lwn.net/Articles/609740/
[+] [-] qb45|8 years ago|reply
Thanks, I just realized that my Arch installation has nih-emd-resolved enabled as the default backend for glibc getaddrinfo and friends. This is how it happens:
https://www.freedesktop.org/software/systemd/man/nss-resolve...
I'm not responsible for any harm to systemd resulting from the use of this information ;)
edit:
And yes, the current version of the package is 232, built in January, so should be vulnerable.
[+] [-] RussianCow|8 years ago|reply
[+] [-] vhvhbbv|8 years ago|reply
[deleted]
[+] [-] userbinator|8 years ago|reply
https://lists.dns-oarc.net/pipermail/dns-operations/2016-Jun... discussed at https://news.ycombinator.com/item?id=11845051
The 3rd bullet point is worth reading several times, in order to take in the absurdity of it all.
[+] [-] 5ilv3r|8 years ago|reply
As nation states are hording zero days, and the security sheep herd insists updates are the way to go, I have never been more convinced that sticking to an OLD AND TRUSTED source code base for your infrastructure is the way to go. You can pop layers on top of that to get newer software running if you like, but trying to keep up with this psuedo-rolling-release avalanche of crap coming down the pipe is not a fair burden for administrators to handle. The devs need to shove it because we don't want it. I am hoping the next economic recession starves out the enthusiasm for disposable infrastructure and "move fast and break things" and businesses can go back to focusing on long term stability.
[+] [-] rsync|8 years ago|reply
I recently (2016) built a little network appliance for a specific task that needed to be safe and secure.
I used FreeBSD 4.11.
[+] [-] avian|8 years ago|reply
Jessie is not vulnerable.
Stretch is vulnerable (no patch yet), but systemd-resolved is not enabled by default.
https://security-tracker.debian.org/tracker/CVE-2017-9445
[+] [-] throwawaymanbot|8 years ago|reply
I'm sick of Linux Servers I use, being "improved" with Desktop implementation in mind.
[+] [-] setq|8 years ago|reply
And you can't criticise it anywhere (watch the downvotes).
The problem is it lacks the mysterious as in Zen and the Art of Motorcycle Maintenance class "quality". Merely glitter around a turd.
However we're stuck with it so it's suck it up or move on.
On the subject of moving on, you could run FreeBSD to run your servers. Much lower resource overheads, native ZFS, simple service management, some documentation worth more than toilet paper and the best thing of all, more sleep at night. Now there are binary updates and packages it's pretty easy. No more make world of any of that stuff.
[+] [-] hhw|8 years ago|reply
It's also fairly transparent that RedHat would like Linux to be more obfuscated so that more enterprises will have to depend on it for support. But that's no surprise. What was surprising was that the Debian foundation not only opted to adopt systemd, but did so long before it was anywhere near proven to be stable, reliable code. This is contrary to their longstanding methodology. Ubuntu's adoption of systemd was simply the result of following Debian upstream. If only enough people could organize Debian to reverse course on systemd, if only until systemd proves to be stable and reliable (likely never). However, let's not pretend this is the first time that Linux has deviated from traditional UNIX and compatibility. There's always been Linuxisms, systemd is just by far the most egregious case.
FreeBSD has really come of age with pkgng though, and I'm happy to see it garner more attention now due to systemd woes. It has always excelled in certain ways, which is why Whatsapp was able to scale to millions of connections on a single box way back in 2012, its process/thread scheduling resulting in more responsiveness under load, better packet filtering, containerization much earlier on (jails), native ZFS, etc.
[+] [-] yuhong|8 years ago|reply
Not to mention Kay Sievers which was even hated by Linus Torvalds: https://lkml.org/lkml/2014/4/2/420
[+] [-] 5ilv3r|8 years ago|reply
[+] [-] sunseb|8 years ago|reply
[+] [-] digi_owl|8 years ago|reply
[+] [-] Mic92|8 years ago|reply
[+] [-] Filligree|8 years ago|reply
Someone would ask this sooner or later, so.. why is this written in C, really?
[+] [-] digi_owl|8 years ago|reply
The shoggoth keep sprouting pseudopods as devs gets bored and think they can reimplement a time tested daemon in a weekend.
[+] [-] a3n|8 years ago|reply
[+] [-] notalaser|8 years ago|reply
When systemd was started, Rust barely had a working compiler and go had been announced for about one year.
[+] [-] revelation|8 years ago|reply
Like, this stuff was built tens of years ago and that code is crappy too but we have pretty much got rid of the most obvious security issues. Nobody wants to relive history so you can finally implement a broken DNS client.
[+] [-] FridgeSeal|8 years ago|reply
[+] [-] Koshkin|8 years ago|reply
[+] [-] 4ydx|8 years ago|reply
[+] [-] tormeh|8 years ago|reply
[+] [-] ausjke|8 years ago|reply
https://devuan.org/
[+] [-] alsadi|8 years ago|reply
Some one called a title another systemd's vulnerability a click biat
Quote
Try to guess what title catches more clicks: 1. CVE-2017-9445: systemd Hit By New Security Vulnerability 2. CVE-2017-9445: systemd-resolved, which is not recommended on most systems and isn't used outside of Ubuntu Hit By New Security Vulnerability
[+] [-] the_common_man|8 years ago|reply
[+] [-] teksimian|8 years ago|reply
[+] [-] JdeBP|8 years ago|reply
* https://github.com/systemd/systemd/pull/5998
* https://news.ycombinator.com/item?id=14451642
[+] [-] unknown|8 years ago|reply
[deleted]
[+] [-] unknown|8 years ago|reply
[deleted]
[+] [-] TotallyGod|8 years ago|reply
[+] [-] qb45|8 years ago|reply
[+] [-] 5ilv3r|8 years ago|reply
[+] [-] ausjke|8 years ago|reply
[+] [-] jaimehrubiks|8 years ago|reply
[+] [-] agwa|8 years ago|reply
[+] [-] chillydawg|8 years ago|reply
[+] [-] Etzos|8 years ago|reply
Edit: It seems Ubuntu builds it together with systemd so users have no choice. There may be a good technical reason for this, but I'm not sure what it is because it seems very user-hostile to remove choice like this.
Edit2: Upon further inspection this appears to be common practice, you just don't enable the parts you don't want. It would be nice if they could be put into separate packages or something of that nature though.
[+] [-] runn1ng|8 years ago|reply
[+] [-] setq|8 years ago|reply
[+] [-] fetbaffe|8 years ago|reply
[+] [-] tyingq|8 years ago|reply
[+] [-] rurban|8 years ago|reply
[+] [-] danirod|8 years ago|reply
[+] [-] pietroalbini|8 years ago|reply
[+] [-] TimWolla|8 years ago|reply