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

141–150 of 162 posts

Re: Systemd v228 local root exploit

#141

Post by bandrami »

scrollaway wrote: post #137
bandrami wrote: post #120

Earlier quoted context omitted.

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 a…

That's because systemd by default is asynchronous, whereas init by default is linear. It's the main feature of systemd: Execution order is usually not important, it only leads to slower boot. For when it is important, systemd can guarantee execution order by using its dependency system. Are you a distro maintainer? I've never heard that it was "hell for distribution maintainers", quite the opposite. What's the issue…

I "maintain" a toy "distribution", that isn't a "distribution" in the sense that I think nobody has ever downloaded it.

What I meant was that the systemd opaque declarative model makes the distribution maintainer's life a lot easier; if systemd manages state based on declarative statements, you just have to make the declarative statements. Under init, you had to make imperative commands that met broad enough conditions to work for everyone.

Re: Systemd v228 local root exploit

#142

Post by ajross »

JdeBP wrote: post #140
ajross wrote: post #126

Earlier quoted context omitted.

> 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. The performance overhead of the script-heavy init system that preceded it is in fact one of the core design points of systemd. Boot time still matters in some environments, and the old init scripts were completely out of hand.

> the script-heavy init system that preceded it ... was the non-shell-script upstart on at least two major operating systems, for quite a few years. * http://uselessd.darknedgy.net./ProSystemdAntiSystemd/ * http://blog.darknedgy.net/technology/2015/09/05/0/

Poeterring works for Red Hat and it was written on Fedora. Yes, Ubuntu had something else. I don't see how that's relevant to a discussion of systemd's design goals.

Re: Systemd v228 local root exploit

#143

Post by scrollaway »

bandrami wrote: post #141
scrollaway wrote: post #137

Earlier quoted context omitted.

That's because systemd by default is asynchronous, whereas init by default is linear. It's the main feature of systemd: Execution order is usually not important, it only leads to slower boot. For when it is important, systemd can guarantee execution order by using its dependency system. Are you a distro maintainer? I've never heard that it was "hell for distribution maintainers", quite the opposite. What's the issue…

I "maintain" a toy "distribution", that isn't a "distribution" in the sense that I think nobody has ever downloaded it. What I meant was that the systemd opaque declarative model makes the distribution maintainer's life a lot easier; if systemd manages state based on declarative statements, you just have to make the declarative statements. Under init, you had to make imperative commands that met broad enough conditio…

Sorry, I read your post the wrong way around.

I think you're conflating "transparent" and "deterministic".

Init is more transparent in that there are less layers to it. But systemd is more deterministic because it is able to make more guarantees about the state of the system.

Similarly, docker is also more opaque but far more deterministic than a provisioning script.

Re: Systemd v228 local root exploit

#144

Post by JdeBP »

ajross wrote: post #142
JdeBP wrote: post #140

Earlier quoted context omitted.

> the script-heavy init system that preceded it ... was the non-shell-script upstart on at least two major operating systems, for quite a few years. * http://uselessd.darknedgy.net./ProSystemdAntiSystemd/ * http://blog.darknedgy.net/technology/2015/09/05/0/

Poeterring works for Red Hat and it was written on Fedora. Yes, Ubuntu had something else. I don't see how that's relevant to a discussion of systemd's design goals.

Fedora was one of those two systems, using upstart since Fedora 9. If you are going to participate in a systemd discussion, you should know what you are talking about, lest you once again (as indeed you are) promote the There Is Only System 5 init And systemd fallacy. Read the Uselessd Guy's articles already pointed to. Read the Debian Hoo-Hah where there were four choices. Read Lennart Poettering's own explanation, widely published a couple of years ago now, of how upstart was the motivator.

Re: Systemd v228 local root exploit

#145

Post by kasabali »

gshulegaard wrote: post #98
grhmc wrote: post #68

Earlier quoted context omitted.

This is frequently how the linux kernel operates.

Just to be clear, systemd is not part of the Linux kernel. Also, if you are going to make a broad claim like that I would appreciate some citations/examples. I have no idea if you are wrong or right on the whole, but without examples I can't learn myself.

> if you are going to make a broad claim like that I would appreciate some citations/examples

It's a common knowledge for people who are familiar with linux kernel development procedures. For starters you can search for two examples off the top of my head, "dirt cow" , "masturbating monkeys" or gregkh tty vulnerability. I'm sure you'll find dozens of other examples if you are sincere in your interest.

Re: Systemd v228 local root exploit

#146

Post by ioquatix »

jhasse wrote: post #78
ioquatix wrote: post #73

Earlier quoted context omitted.

Let's say you write some authorisation code using JavaScript. If it contains a syntax error, or a logic error your authentication is broken for your entire system. Checking the correctness of a program is usually non-trivial, but I accept some things CAN be checked (e.g. syntax). However, JavaScript, naturally is a procedural language and hence the bulk of your problems would be in your logic. In contrast, /etc/sudoe…

What if the program reading /etc/sudoers{.d} has a bug and crashes?

Then.. sudo has a bug and should be fixed?

Re: Systemd v228 local root exploit

#148

Post by bandrami »

scrollaway wrote: post #143
bandrami wrote: post #141

Earlier quoted context omitted.

I "maintain" a toy "distribution", that isn't a "distribution" in the sense that I think nobody has ever downloaded it. What I meant was that the systemd opaque declarative model makes the distribution maintainer's life a lot easier; if systemd manages state based on declarative statements, you just have to make the declarative statements. Under init, you had to make imperative commands that met broad enough conditio…

Sorry, I read your post the wrong way around. I think you're conflating "transparent" and "deterministic". Init is more transparent in that there are less layers to it. But systemd is more deterministic because it is able to make more guarantees about the state of the system. Similarly, docker is also more opaque but far more deterministic than a provisioning script.

No, we're just thinking about determinism differently.

Systemd makes (or at least tries to make) guarantees about outcomes, which means it doesn't make guarantees about process. SysV (at least the traditional BSD-style a la Slackware) makes guarantees about process, which means it doesn't make guarantees about outcomes. I prefer determinism of process to determinism of outcome.

Re: Systemd v228 local root exploit

#149

Post by lmm »

tveita wrote: post #138
lmm wrote: post #65

Earlier quoted context omitted.

Not necessarily. If any unsafe constructs are locally visible during code review, and the language is such that unsafe constructs are rarely required, then it's much easier to give unsafe constructs a higher level of scrutiny that you can't afford to do in a language like C where unsafe things are pervasive and the same line can easily be safe in one context and unsafe in another.

"during code review". But did this code go through code review? If not your "higher level of scrutiny" are still not high enough to warrant mention.

I don't know about SystemD's code policies. But certainly serious vulnerabilities have been found even in C code where changes went through code review (the famous Chrome sandbox escape due to an undefined bitshift was noted to have been reviewed and explicitly "LGTMed" by two people).

And the decision about whether to code review is not necessarily static. A language that reduces the cost and/or increases the benefits of code reviews changes the decision space. And a more expressive language can free up developer time to spend on things like code review.

Re: Systemd v228 local root exploit

#150

Post by tinus_hn »

JdeBP wrote: post #114
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…

Okay, so the problem arises due to:

* bad luck so a signedness issue doesn't cause a warning

* the use of the worst possible value as the invalid value

* no testing

* no defense in depth: no other component in the system appears to notice a file with such a dangerous mode set

Post reply on HN