Systemd v228 local root exploit

[implr]

>We would like to see that systemd upstream retrieves CVE's themself for their own bugs, even if its believed that its just a local DoS.

So not only they didn't notice this was exploitable, they also seem to think that a local DoS is not enough for a CVE or a public report. Excellent.

[KuiN]

This is the really concerning part. silently fixed in the upstream git is not at all an acceptable way to deal with serious security flaws in your product.

[bkor]

CVE is an invite only system, applied to just a few projects. See e.g. https://cve.mitre.org/cve/data_sources_product_coverage.html. Generally you need to know someone to get such an id.

If you have a bug in some github project you cannot request a CVE for that. If a CVE is reported you'd usually include that in the commit. But that's not the same as every security bug should have a CVE. Often way easier to just fix bugs instead of figuring out if it is a security bug (=method Linus uses).

[jsmeaton]

Hanlon's Razor; perhaps whoever wrote/merged the patch didn't consider the possibility of an exploit?

[galapago]

> they also seem to think that a local DoS is not enough for a CVE

Some vendors do not consider local DoS as security issues. I tried to discuss these kind of issues in oss-security but even MITRE refused to assign a CVE.

[ioquatix]

Did you know that polkit, the systemd replacement of sudo, uses JavaScript to validate permissions?

This was the response: https://lists.freedesktop.org/archives/systemd-devel/2016-De...

systemd is a bomb waiting to go off, IMHO.

[throwawayish]

I'm not aware of server or desktop OS that isn't generally vulnerable to local DoS.

[kogepathic]

> "new services as a service"

Accurately describes systemd's development over the past few years.

[api]

Local security on Linux is completely forfeit. It's a single user OS. Anyone with access has root. There's just too much surface area between all the different subsystems and nobody's been paying much attention to local security for a very long time.

I've thought for a long time that containers and even virtualization are kind of a parody of this. They shouldn't be necessary. If the OS had good multi-tenancy, resource control, and local security you could have multiple tenants (even untrusted ones!) on the same "box" without requiring any of those layers of complexity.

[bandrami]

Why does systemd implement touch(1) as a library function? Isn't the whole point of coreutils to keep stuff like that centrally maintained so we don't have a million different (and possibly broken) implementations of it?

[loeg]

Fork and exec is an absurdly expensive way to implement what is essentially open().

You might instead ask, why doesn't coreutils provide a libcoreutils, with touch(1) a thin shim around that? And then systemd could use that.

[mangix]

Fun fact: the person who fixed this is an Arch Linux developer. The whole issue based on the commit seems like an oversight (thinking mode_t is signed).

This doesn't appear to be malicious in any way. Note that many apps have sign issues like these, with the difference being that it's not enough to give root.

[dijit]

I do not doubt that issues like this will become more common in future. Code quality/clarity is nearing that of OpenSSL.

[belorn]

v228 is too new for Debian stable. Unstable had a update on feb 11, 2016.

Ubuntu never ran with such early version, since their first uploaded version was 229.

[lclarkmichalek]

If you are on a systemd system, you can check your version with

    $ init --version
    systemd 231
    +PAM +AUDIT +SELINUX +IMA -APPARMOR +SMACK -SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT -GNUTLS -ACL +XZ -LZ4 +SECCOMP +BLKID -ELFUTILS +KMOD -IDN

[baq]

here's the fix: https://github.com/systemd/systemd/commit/06eeacb6fe029804f2...

questions to the local experts:

1) would using a differently designed open() api prevent the issue?

2) would not using C to write systemd prevent the issue? specifically, would using rust, ocaml, ats or ada prevent the issue?

[benmmurphy]

2) maybe. mode_t is unsigned and MODE_INVALID was defined as: #define MODE_INVALID ((mode_t) -1) and the problem was in a check: fd = open(path, O_WRONLY|O_CREAT|O_CLOEXEC|O_NOCTTY, mode > 0 ? mode : 0644);

so maybe the author thought MODE_INVALID < 0. though, maybe safe languages will let you do this explicit cast as well so maybe they won't save you.

the other thing is maybe in a safe language you would use an Option/Maybe type here instead of a plain mode_t type.

[zakk]

> mode_t is unsigned, so MODE_INVALID < 0 can never be true.

Wouldn't GCC complain about a comparison which is always true?

[twoodfin]

benmmurphy's comment below points out that the flawed test was "mode > 0".

https://news.ycombinator.com/item?id=13470516

[Esau]

It's a shame that SystemD, has this issue. Hopefully, once the fix is made, they can get back to the business of obfuscating the init process.

[jwilk]

> SystemD

https://lists.debian.org/[email protected]

[d33]

:D

I know you're joking, but it's a nice way to say what they basically do.

EDIT:

I elaborated here: https://news.ycombinator.com/item?id=13470953

[josteink]

> Surprise surprise...

About as surprising as seeing completely content-less anti-systemd comments like yours popping up, really.

[oblio]

(Future readers can safely ignore the rest of the comment, I was struck by the "did not read the article" disease)

Surprised that software has security flaws? Especially software written in "let-me-use-that-chainsaw-to-trim-the-bushes" C? :)

I know that there will be security flaws in any language, but if there ever was software today that deserved a safer programming language, the init system was it. Or the web browser.

[avian]

The "sysvinit" binary package has had a total of 2 bug reports tagged "security" filed in Debian's bug tracker. That's over the entire history of the package that goes back to at least 2004.

If I extend the search to all packages built from the "sysvinit" source (which includes packages like initscripts and sysvinit-utils), the count increases to 8.

(source: https://www.debian.org/Bugs. I'm not linking to exact queries since they take quite some time and HN has a tendency of taking down Debian's bug tracker)

[jsjsjsjsjsjs]

I wonder what security problems Linux kernel had in that time?

Other init systems (probably) had no exploits because dull rock can be exploited only so much.

[x0]

You're right. Ever since distros made systemd default, computers all over the world have been catching fire, exploding, shooting jets of lava from their headphone jacks. It's the end times

[tinus_hn]

Why does systemd have functionality to create files as root for unprivileged users anyway? What's the point?

[djsumdog]

I don't like systemd, but for the benefit of the doubt. One of the dangerous lines of code is in a touch_file function:

https://github.com/systemd/systemd/blob/ee735086f8670be1591f...

..and most init systems do have a legitimate use case for touching a file.

[JdeBP]

systemd does not have such functionality. You have not read the headlined message correctly.

Rather, it has functionality to "touch" files in sensitive places, and a bug that meant that they were made world-writable, world-executable, and set-UID. The headlined message alludes to the various uses of this touch function that expose such files to the world to be exploited in certain circumstances, which (amongst others) are:

* timestamp files for timer units

* device tags files in systemd-udev

* /run/udev/queue

* timestamp files used by timesyncd

* private devices, bind mounts, and mirrored /etc/resolv.conf created by systemd-nspawn

* "linger" flags used by systemd-logind

* temporary files used by "systemctl edit"

* All sorts of flag files: /run/systemd/journal/flushed , /run/systemd/quotacheck , /run/systemd/show-status , /run/systemd/first-boot

[snuxoll]

Runtime directories, socket files, etc.