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

71–80 of 162 posts

Re: Systemd v228 local root exploit

#71

Post by jacobmischka »

ioquatix wrote: post #39
implr wrote: post #4

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

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.

I think your being so quick to judge anything using JavaScript as inherently bad is silly, but this link just made me realize that using sudo with systemd as I had been seems to be incorrect, so thanks for the link.

Re: Systemd v228 local root exploit

#72

Post by JdeBP »

jwilk wrote: post #44
Esau wrote: post #21

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.

> SystemD https://lists.debian.org/878ttl9go6.fsf@hope.eyrie.org

Same subject, same mailing list, two months earlier:

* https://lists.debian.org/debian-devel/2016/08/msg00547.html

Re: Systemd v228 local root exploit

#73

Post by ioquatix »

jacobmischka wrote: post #71
ioquatix wrote: post #39

Earlier quoted context omitted.

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.

I think your being so quick to judge anything using JavaScript as inherently bad is silly, but this link just made me realize that using sudo with systemd as I had been seems to be incorrect, so thanks for the link.

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/sudoers{.d} config is syntactically validated using a strict grammar so that it can be validated for correctness before being loaded and used (hence visudo). It's primarily a declarative language too which means that logic bugs aren't really possible. This means that there is a robust mechanism to detect syntax issues (and some semantic issues) before breaking your system.

Re: Systemd v228 local root exploit

#74

Post by ungamed »

grhmc wrote: post #68
KuiN wrote: post #22

Earlier quoted context omitted.

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.

This is frequently how the linux kernel operates.

The distro vendors are the ones who frequently pull apart commit logs to be documented.

Re: Systemd v228 local root exploit

#75

Post by theamk »

adrianN wrote: post #13
mfukar wrote: post #9

Earlier quoted context omitted.

It's not the logic of hammering my own fingers that is flawed, it is my choice of a hammer!

You can program touch() to create files with 0777 rights in any language, not just C.

Yes, but other languages would use optional or special null-like value which cannot be automatically converted into integer.

Re: Systemd v228 local root exploit

#76

Post by ioquatix »

lordlimecat wrote: post #64
gravypod wrote: post #62

Earlier quoted context omitted.

" Polkit (formerly PolicyKit) is a component for controlling system-wide privileges in Unix-like operating systems. " Calling it the sudo for UIs seems reasonable. It lets you manage the permission level of the UI you're using. Does it do something else?

Youre being too generous. GP's statement was, "Did you know that polkit, the systemd replacement of sudo," He calls it a replacement of sudo which is is definitely not.

Uh, so, systemd don't recommend to use `sudo systemctl start blah`. Their idea is to use `systemctl start blah` and have polkit handle the authentication. Not sure what's unclear here.

Re: Systemd v228 local root exploit

#77

Post by jhasse »

ioquatix wrote: post #76
lordlimecat wrote: post #64

Earlier quoted context omitted.

Youre being too generous. GP's statement was, "Did you know that polkit, the systemd replacement of sudo," He calls it a replacement of sudo which is is definitely not.

Uh, so, systemd don't recommend to use `sudo systemctl start blah`. Their idea is to use `systemctl start blah` and have polkit handle the authentication. Not sure what's unclear here.

The difference is that with `sudo systemctl ...` systemctl is run as root, but with PolicyKit only parts are. And if I understand it correctly PolicyKit allows more fine grained control over permissions than sudo.

Re: Systemd v228 local root exploit

#78

Post by jhasse »

ioquatix wrote: post #73
jacobmischka wrote: post #71

Earlier quoted context omitted.

I think your being so quick to judge anything using JavaScript as inherently bad is silly, but this link just made me realize that using sudo with systemd as I had been seems to be incorrect, so thanks for the link.

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?

Re: Systemd v228 local root exploit

#79

Post by crest »

ioquatix wrote: post #39
implr wrote: post #4

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

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.

Sudo and polkit are so complicated because they solve the wrong problem. The common problem is how do I execute code under a different effective user id. Instead they try to solve a much harder superset: how to securely implement a policy defining who is allowed to execute what under which effective user id in a setuid executable.

There are much simpler solutions without setuid: https://skarnet.org/software/s6/s6-sudo.html.

Re: Systemd v228 local root exploit

#80

Post by bkor »

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…

> The project has much too much responsibility, handling parts of system that could easily be delegated to separate projects.

That makes on sense. Systemd provides some basic building blocks. Splitting systemd across multiple projects only provides drawbacks, no benefits.

systemd does NOT interfere with GNOME. It provides logind and some other bits which GNOME makes use of.

Talking about "ad personam" is a bit weird if there's so much misinformation.

Post reply on HN