Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Systemd v228 local root exploit

openwall.com

Post reply on HN
Print view View original

111–120 of 162 posts

Re: Systemd v228 local root exploit

#111

Post by dandelion_lover »

throwawayish wrote: post #108
dandelion_lover wrote: post #101

Earlier quoted context omitted.

Qubes OS

As a Qubes user, no, not at all. It's fairly easy to starve other VMs of resources. Qubes is more vulnerable here than other systems, due to it's dynamic allocation of memory. A VM that has a no-matter-what fixed limit of say 2 GB RAM would have a harder time to cause trouble there, but the dynamic management done by Qubes is a major selling point, otherwise it wouldn't be really practical to use on mobile hardware (…

As a Qubes OS user, yes, you can disable the dynamic memory allocation for chosen VMs. So I do not see the problem.

Upd: right click in Qubes Manager, VM settings, Advanced, Include in memory balancing, remove the tick.

And you can even choose how many CPU cores a VM can use.

Re: Systemd v228 local root exploit

#112

Post by simias »

benmmurphy wrote: post #30
baq wrote: post #26

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?

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 the other thing is maybe in a safe language you would use an Option/Maybe type here instead of a plain mode_t type.

The same error could technically occur in Rust if the API was designed that way but I think the "Rust way" would mandate using an `Option` instead of a special MODE_INVALID value.

So it would become something like `mode.unwrap_or(0o644)` which doesn't leave a lot of room for error.

Re: Systemd v228 local root exploit

#113

Post by bandrami »

loeg wrote: post #109
bandrami wrote: post #94

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?

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.

Sure, security has performance costs, but I don't think an init system (whose job, ultimately, is to fork and exec a lot of things) is going to be harmed by it.

And, anyways, if you had a libcoreutils, suddenly you're stuck worrying about symbol versions, LD_PRELOAD, etc., etc., whereas simply executing the binary is pretty simple.

Re: Systemd v228 local root exploit

#114

Post by JdeBP »

tinus_hn wrote: post #67

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

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

Re: Systemd v228 local root exploit

#115

Post by xena »

bandrami wrote: post #93
djsumdog wrote: post #69

Earlier quoted context omitted.

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.

If only UNIX provided an existing utility to do that...

So you want pid1 constantly calling out to userland binaries to do basic filesystem manipulation tasks?

Re: Systemd v228 local root exploit

#116

Post by geofft »

gens wrote: post #100
geofft wrote: post #86

Earlier quoted context omitted.

Polkit gets remarkably close. You can use polkit to define rules so an unprivileged user can call "systemctl restart ...", which sends an unprivileged message over D-Bus to pid 1, which checks authorization and then does the task if the requestor is authorized. Polkit just also ships with pkexec and similar things in the sudo mindset.

The problem is that you have many things to configure instead of just one. That is a problem as we humans have a limited capacity for remembering things. On top of that polkit is basically javascript and xml (i think), and one can not expect everybody to understand javascript or have the patience to read/write xml. Now, in addition to groups and users (and advanced fs permissions and app/se/linux/armor), you have pol…

I'm not going to defend polkit's choice of JS, but I have to say it's funny to see a complaint about Turing-complete configuration files when the usual anti-systemd sentiment prefers sysvinit Turing-complete shell scripts to systemd declarative configuration files :)

Re: Systemd v228 local root exploit

#117

Post by bandrami »

d33 wrote: post #57
scrollaway wrote: post #52

Earlier quoted context omitted.

You are making a comment about "The development process [being] too fast and erratic" (it is not). I'm not defending the systemd process, I'm making a point about that. Then again, if you think "obfuscating the init process" is a valid description of what systemd does per your other comment, I'm having a hard time seeing this as anything other than armchair security expertise...

You just resorted to ad personam for the second time. This is my last post in this discussion because of that. Here's why I believe it obfuscates the init process - it clearly is less transparent now. Consider logging, consider a new DSL (in terms of keywords, not necessarily syntax) needed to describe services, consider lack of determinism it brings. Yes, it's faster, but definitely more opaque. As for development p…

I still don't see how this is even a question. Of course it's more opaque; declarative systems are by nature (that's generally a selling point).

The fact that most distros seem to package a brittle spaghetti mess of unit files symlinked into about 7 different places isn't particularly systemd's fault, of course, but even when they're done more sanely just by nature declarative is always more opaque than imperative.

Re: Systemd v228 local root exploit

#118

Post by JdeBP »

JdeBP wrote: post #97
benmmurphy wrote: post #30

Earlier quoted context omitted.

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 the other thing is maybe in a safe language you would use an Option/Maybe type here instead of a plain mode_t type.

It wasn't really anything to do with the language, and far more to do with the operating system kernel API. The fchown() system call supports passing -1, cast to the appropriate type, as a no-op value. The systemd people were attempting to wrap similar semantics around fchmod(). Originally in 2014 M. Sievers specified (mode_t)0 as the no-op value, which wasn't a good choice, with M. Poettering changing it to (mode_t)…

Incidentally: M. Sievers' original choice of (mode_t)0 as a no-op value lives on to this day in systemd-udevd.

* https://github.com/systemd/systemd/blob/v232/src/udev/udev-r...

Re: Systemd v228 local root exploit

#119

Post by bandrami »

xena wrote: post #115
bandrami wrote: post #93

Earlier quoted context omitted.

If only UNIX provided an existing utility to do that...

So you want pid1 constantly calling out to userland binaries to do basic filesystem manipulation tasks?

Well, I want PID 1 to make exactly one userland binary call and then start reaping orphans. I want that PID 2, the RC system, to read some configuration file(s) and, yeah, fork and exec a bunch of userland binaries. It's kind of the whole point, right?

Re: Systemd v228 local root exploit

#120

Post by bandrami »

scrollaway wrote: post #60
d33 wrote: post #57

Earlier quoted context omitted.

You just resorted to ad personam for the second time. This is my last post in this discussion because of that. Here's why I believe it obfuscates the init process - it clearly is less transparent now. Consider logging, consider a new DSL (in terms of keywords, not necessarily syntax) needed to describe services, consider lack of determinism it brings. Yes, it's faster, but definitely more opaque. As for development p…

> You just resorted to ad personam for the second time. ...? I realized my first post was unnecessarily sarcastic and edited that part out. It's hard to comment about your opinions without talking about your opinions . But okay, you've offered a list, let's go through it: > Consider logging Logging is in a binary format, but is more consistently accessible. > consider a new DSL In terms of keywords? Do you mean like,…

sysvinit brings far less determinism to the table

Hm. I was with you until that. The reason I don't have systemd in production is that it's like pulling teeth to get a deterministic service initiation order. For all their flaws, the good thing about init.d scripts was that you knew exactly what order things came up and down in, because it was spelled out in a shell script you could view and edit.

This was great for administrators, but absolute hell for distribution maintainers; I totally get why the distros went to systemd. But since it solves their problems, rather than mine, it's not particularly useful to me (I use GNU PIES in production, which is kind of a middle ground: it can run inittab and rc.d scripts, but it also has a declarative native format)

Post reply on HN