
Ubuntu Systemd Vulnerability - ingve
https://www.ubuntu.com/usn/usn-3341-1/
======
agwa
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.

[1] [https://www.freedesktop.org/software/systemd/man/systemd-
res...](https://www.freedesktop.org/software/systemd/man/systemd-
resolved.service.html)

[2] See [http://seclists.org/oss-sec/2014/q4/592](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/](https://lwn.net/Articles/609740/)

~~~
RussianCow
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"?

~~~
5ilv3r
It's more about dbus, really. They are trying to get rid of 'everything is a
file' and move to a pub/sub service model.

~~~
rsync
"They are trying to get rid of 'everything is a file' and move to a pub/sub
service model."

I thought we were trying to move _towards_ "everything is a file" ... isn't
that the goal of the plan9/Inferno movement ?

I thought _that_ was the progressive direction in UNIX design.

We want to move _away from_ "everything is a file" ?

~~~
deno
Everything is a file ≠ everything is a blob/adhoc plaintext interface.

DBus is a much superior “everything is a file” abstraction, except DBus calls
files objects and doesn’t special-case directories.

Quick comparison:

Inode — Client address

.. e.g. 3597293 — :1.32

Mount points — Well-known addresses

.. e.g. /proc/subsystem — org.foo.subsystem1

Directory/file hierarchy — Object hierarchy

.. e.g. /foo/bar/xyz — /foo/bar/xyz

Implicit RPC — Explicit RPC

.. e.g. IOctl or echo "foo" > /foo/bar — org.foo.Interface1.methodFoo(int,
int, string)

Security

.. sudo vs Polkit

etc.

~~~
wahern
> Everything is a file ≠ everything is a blob/adhoc plaintext interface.

Actually, yes, it more or less means exactly that. Everything is a file means
your interfaces (i.e. object methods) are generally limited to open, read,
write, and close. Of course you can synthesize whatever you want on top of
that, but the basic contract relies on those primitives exclusively.

~~~
deno
And this is better how exactly?

~~~
wahern
Ever try to use a dbus service from the shell? From any language that
_doesn't_ rely on a binding to the C library? Therein lies your answer.

It's like ioctl. The ioctl interface is an abomination precisely because it
breaks the open/read/write/close interface. Ever try to use an ad hoc ioctl
interface from any language other than C or C++?

If all the world used the same programming language with the same control flow
constructs then a strongly typed RPC interface would make a ton of sense. But
it doesn't.

The everything-is-a-file contract works well for the same reason that IP works
well: because it pushes the complexity to the edges, and when the technology
changes you don't need to upgrade every piece of middleware.

Almost every modern language supports open, read, write, and close from day 1,
giving you the necessary primitives to communicate with anything supporting
that model. Of course, maybe batteries aren't included and you have to do some
grunt work. But that's often the interface designers fault. Opening a TCP
connection on Plan 9 is as easy as a single open call, vs multiple complex
system calls using a more typed interface like the BSD Sockets API.

Even dbus can be exported through the file model. Theoretically you could
expose dbus through the filesystem namespace using something like FUSE. And,
actually, here's an attempt at that:
[https://github.com/sidorares/dbusfs](https://github.com/sidorares/dbusfs)
Which goes to show how flexible the open/read/write/close model truly is.

~~~
deno
> Ever try to use a dbus service from the shell? From any language that
> _doesn't_ rely on a binding to the C library Therein lies your answer.

There are many libraries that do not bind to libdbus. GLib’s, QT’s and outside
of C/C++ you have native python (txdbus), native javascript (node-dbus, which
is btw powering the dbusfs you linked) and native C#/mono. That’s just off the
top of my head, I’m sure there are many more.

As for shell, I am not a fan, obviously, but qt-dbus (and the glib one) has
existed for a long time and busctl is even nicer. Works just fine if you just
need the client functionality.

DBus lends itself to something much more powerful like Microsoft’s Powershell
(but without the CLR). Bash is obviously designed for filesystem interface, it
also is not a great fit for SQL. Doesn’t mean SQL is shit.

> Which goes to show how flexible the open/read/write/close model truly is.

It‘s useless, not flexible.

Everything has some ad-hoc implied interface, documented who knows where, if
at all, and this giant hack is somehow something to admire?

Garbage-in, garbage-out. I’ll take DBus any day.

> Theoretically you could expose dbus through the filesystem namespace using
> something like FUSE.

You can expose the filesystem via DBus as well (e.g. org.gtk.vfs). Shows you
how flexible DBus is.

~~~
JdeBP
At this point in the discussion, I am reminded of
[http://gentooexperimental.org/~patrick/weblog/archives/2014-...](http://gentooexperimental.org/~patrick/weblog/archives/2014-11.html#e2014-11-23T09_26_01.txt)

------
userbinator
A year ago, there was this:

[https://lists.dns-oarc.net/pipermail/dns-
operations/2016-Jun...](https://lists.dns-oarc.net/pipermail/dns-
operations/2016-June/014964.html) discussed at
[https://news.ycombinator.com/item?id=11845051](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.

~~~
kuschku
On the other hand, it improves safety and security for many users.

Because on most distros, using unbound or BIND9 as local DNS server, they bind
to all interfaces, publicly.

Which is the reason why DNS amplification DDoS even is possible.

I’ve seen it often enough happen, and basically every person who’s set up
their own servers has made the mistake of leaving the defaults.

~~~
lottin
But who runs a DNS server? 99% of users only do DNS resolution and for that
you don't need to run a DNS server on your system.

~~~
kuschku
Many people run a DNS server to cache DNS responses locally. And they don’t
want to expose the DNS server publicly. systemd-resolved does that, you can’t
even expose it accidentally.

But many distros actually install a DNS server by default, usually unbound or
BIND9, and while some bind it to localhost, many bind it to all interfaces.

As you said, that’s not necessary for most users, yet, major distros do it.

~~~
pgl
Which distros install a DNS server (and enable it) by default? I've never seen
this.

~~~
barrkel
dnsmasq has been installed as a local DNS cache on Ubuntu and other Debian
derivatives for many years. /etc/resolv.conf normally points at localhost.

~~~
dsp1234
It only listens on localhost though (127.0.1.1 by default), so it's not
possible for it to be abused for dns amplification attacks.

~~~
dom0
IIRC dnsmasq still listens on all interfaces for some reason

~~~
kuschku
Which is exactly the issue I mentioned.

You get on some distros by default something that that makes you subject to
DNS amplification attacks.

~~~
dom0
It is supposed to reject requests from the _addresses_ it does not listen on.
I just found it strange that it binds on all _interfaces_ regardless.

~~~
kuschku
I’ve noticed it respond with an error packet – which ended up being used for
DNS Amplification nonetheless.

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

~~~
rsync
"I have never been more convinced that sticking to an OLD AND TRUSTED source
code base for your infrastructure is the way to go."

I recently (2016) built a little network appliance for a specific task that
needed to be safe and secure.

I used FreeBSD 4.11.

~~~
qb45
Are you sure it has no remote vulns since it's been discontinued or did I just
prove Poe's law?

~~~
wahern
I think that's called security by obsolescence. Not sure how well that
actually works. Root kits don't just disappear and FreeBSD 4.1 isn't as
obscure as, say, VMS. But as long as there are no remote vulnerabilities it's
probably no worse than a typical Linux install, in the sense that both would
be trivially rootable once you get your foot in the door.

~~~
5ilv3r
Usually with BSD you can apply new patches to old systems without any trouble.
No need to upgrade everything.

~~~
wahern
Maybe FreeBSD is different, but I've run OpenBSD for 17 years and this is
definitely not the case for all BSDs. Because OpenBSD is a cohesive system
they're not afraid to do aggressive refactors. Which means subsystems can
change drastically within just a few release cycles, meaning you can quickly
lose the benefit of further fixes.

For example, just today Theo announced that he's staging the removal of
TIOCSTI, the perilous ioctl that allows injecting data into a process group
TTY. It's a huge break with historical BSD. That means if there's a TIOCSTI
exploit found next year (say, in the NetBSD or FreeBSD code) that effects
OpenBSD 6.0, there won't be an OpenBSD fix to backport; you'll have to craft
one yourself and maintain it going forward.

NetBSD imported Lua 5.1 (IIRC, or maybe Lua 5.2) into their base, then in
later releases upgraded it to Lua 5.3. the difference between Lua 5.1 and Lua
5.3 is like the difference between Python 2 and 3. Plus, Lua 5.1 is completely
unmaintained at this point. If you're on an unsupported NetBSD release don't
expect any fixes coming down the pipe for Lua 5.1.

But I admit that FreeBSD is definitely not OpenBSD, for better and worse, in
terms of the pace of major refactoring work.

------
avian
Current situation in Debian:

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](https://security-
tracker.debian.org/tracker/CVE-2017-9445)

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

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

~~~
smhenderson
_Any other platform is ZERO hassle and that includes windows, OSX, freebsd,
openbsd etc._

I'd add Slackware to that list, at least for now. I've switched some servers
to OpenBSD and a few others to Slackware, plus I've switched to Slackware for
a laptop I use.

I'm cautiously optimistic that Patrick will keep systemd out of Slackware for
the foreseeable future. It is after all one of the most BSD like Linux distros
available.

~~~
rollcat
Add Void Linux to the list, it uses runit.

~~~
digi_owl
Didn't Docker switch to using Void as basis for their container images?

~~~
cyphar
No, alpine. But running systemd in Docker has never /really/ worked (except if
you're running on RHEL because they have a bunch of patches to make it work)
due to how much shit systemd does that makes it hard to run in a container.
Even systemd-nspawn (their container runtime which runs systemd inside the
container) doesn't work in a lot of cases.

LXC is the only runtime I'm aware of that actually runs systemd inside
containers well, but they had to do a lot of unholy shit to play nicely with
systemd.

runc has had countless issues with systemd thinking that it owns the system
and it messing with container cgroups.

And don't get me started on the fact that cgroupv2 is specifically designed to
only work if you have a global management process for cgroups (can you guess
what management process that is?).

~~~
digi_owl
And surprise surprise, the current cgroups maintainer is a Red Hat employee.

I'm not saying it is planned, but i wonder if there is a echo chamber effect
going on...

~~~
setq
He who controls the spice....

~~~
digi_owl
In in this case, the source...

------
sunseb
Let's face it: systemd is a bad design... The solution I found: FreeBSD and
OpenBSD !

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

~~~
talideon
No more so than a Linux distro does.

With the latter, you're referring to base. FreeBSD isn't really any more
monolithic than your average distro in that regard though; it's just that with
some services, the userland, and the like it (historically) made sense to
maintain with particular stable versions of the kernel. Base is being slimmed
down where possible though: bind has been replaced with unbound, dma is likely
going to replace sendmail in FreeBSD 11, IIRC, and now that pkgng is proven,
the process of packaging the base system should be complete for FreeBSD 12,
which will allow freebsd-update to be (mostly) replaced.

------
Filligree
Memory corruption...

Someone would ask this sooner or later, so.. why is this written in C, really?

~~~
digi_owl
Nah, more like why do systemd include anything to do with DNS at all.

The shoggoth keep sprouting pseudopods as devs gets bored and think they can
reimplement a time tested daemon in a weekend.

~~~
sangnoir
> The shoggoth keep sprouting pseudopods as devs gets bored and think they can
> reimplement a time tested daemon in a weekend.

"Ph'nglui mglw'nafh Cthulhu _Raleigh[1]_ wgah'nagl fhtagn" ("In his house at
_Raleigh_ , dead Cthulhu waits dreaming.")

1\. I'm so sorry, but I couldn't keep myself from punning Red-Hat-sponsored
systemd with the Cthulu mythos. For the non-Lovecraft fans, the original city
is named "R'lyeh"

~~~
digi_owl
Lovely. I actually confuse the two from time to time.

------
ausjke
Debian without SystemD

[https://devuan.org/](https://devuan.org/)

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

------
the_common_man
16.04 is not affected

~~~
teksimian
I bet init is also unaffected.

~~~
5ilv3r
14.04 used upstart (also used by chromeos). sysvinit was used in ubuntu prior
to upstart, and there are some distros that use bsd style init. Go read up on
init system options a bit more.

~~~
teksimian
yes, i'm aware of bsd init, sysvinit, upstart, systemd et al.

systemd & upstartd all aim to replace pid 1/init. Which as far as i'm
concerned anything beyond bsd init is over complicating things, and these are
the results.

------
JdeBP
This is not CVE-2017-9217, note.

* [https://github.com/systemd/systemd/pull/5998](https://github.com/systemd/systemd/pull/5998)

* [https://news.ycombinator.com/item?id=14451642](https://news.ycombinator.com/item?id=14451642)

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

~~~
5ilv3r
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.

~~~
pas
K root is operated by RIPE NCC M root is opreated by WIDE from Japan

[http://root-servers.org/](http://root-servers.org/)

Use DNSSEC, it's pretty tamper proof, keys are in HSM and "geo distributed" (
[https://www.schneier.com/blog/archives/2010/07/dnssec_root_k...](https://www.schneier.com/blog/archives/2010/07/dnssec_root_key.html)
), the weak points are probably the facilities themselves in the US (one on
the East Coast and one on the West Coast), but the trust anchor is pretty much
fixed in the root servers, and it'd be quickly discovered if someone rolled a
new one out of schedule.

~~~
tptacek
DNSSEC does absolutely nothing to resolve the problem the parent commenter is
referring to. In fact, DNSSEC _cryptographically ratifies the status quo_ of
the most important TLDs being de-facto controlled by Five Eyes governments.

In years of watching for mentions of DNSSEC on HN, I can't remember off the
top of my head a single case in which DNSSEC was introduced into a
conversation as having some benefit where that benefit was real. It's weird
what people believe about DNSSEC.

~~~
pas
Please elaborate.

Parent seems worried about the root servers serving malicious responses for
any given domain. (While assuming all root servers are under US control.)

In case of a non-US controlled TLD (.ru, .cn, .de, .eu) why DNSSEC is
worthless?

------
ausjke
Debian without systemd: [https://devuan.org/](https://devuan.org/)

------
jaimehrubiks
Does this affect computers that did not ask for such packet (dns response)?

~~~
chillydawg
DNS is UDP so you might just get a broken packet sent to you, I guess?

~~~
icebraining
Only if daemon is listening to the outside, which I _hope_ is not the case by
default.

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

~~~
pietroalbini
I don't exactly know why it's in the same package as systemd, but why do you
consider it an user-hostile decision?

Unless you have so little storage you can't afford to have an extra binary
installed in the system, there is no downside of having it on the machine.

You can still disable the daemon and switch to another one (like dnsmasq), as
if it was in a different package.

~~~
Shish2k
Technically it's not a huge problem; politically, bundling unrelated software
together means that the bundled software has an advantage and a tendency to
get more market share than its competitors who compete fairly. In the case of
open source distros, I'm sure that this isn't _illegal_ , but it seems like it
isn't in the interests of the community.

~~~
pietroalbini
Well, it's clear it doesn't compete fairly with the other daemons, because
it's the default one since Ubuntu 16.10 [1]. So, bundling it with the systemd
package doesn't harm anybody, because you'd have to install another package
anyway to change the default.

[1] [https://lists.ubuntu.com/archives/ubuntu-
devel/2016-May/0393...](https://lists.ubuntu.com/archives/ubuntu-
devel/2016-May/039350.html)

------
runn1ng
"Rewrite It In Rust" should be the default, pre-set comment to every article
about every vulnerability

~~~
tyingq
Maybe every memory access related one. I assume rust still allows you to pass
untrusted user input around, for example.

~~~
zlynx
Oh yeah. Cross site scripting and SQL injections are still perfectly easy to
write in Rust. You can accept a web POST and pass it directly, unquoted, to a
local shell too.

------
danirod
Who could have predicted that bloating PID 1 process could result in funny
CVEs like this!

~~~
TimWolla
systemd-resolved is a separate process (not PID 1) that just was written by
the same authors as systemd-the-pid-1.

~~~
tveita
Maybe there would be less confusion if they changed the name to something not
including systemd, and decoupled the development and distribution of these
clearly unrelated projects.

Then this DNS resolver could get the distribution and usage it deserves based
on its own merits.

Of course, that's not going to happen, because the creators want systemd to be
an OS by itself, with every buggy unreliable component standing as a monument
to them only, and that means strong-arming in projects that could never
compete with the existing working solutions on merits.

~~~
digi_owl
Effectively Freedesktop has given up on defining the Linux desktop by
specification, and have switched to do so by canonical (heh) implementations.

