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

121–130 of 162 posts

Re: Systemd v228 local root exploit

#121

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

Re: Systemd v228 local root exploit

#122

Post by gens »

geofft wrote: post #116
gens wrote: post #100

Earlier quoted context omitted.

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 :)

Do you have any real objections to what i said ? Did i even mention systemd or any sysvinit ?

Polkit is on systems with and without systemd. And, if you just have to pull sysvinit into it, shell scripts are simple (note that permissions to do something are not even remotely related to the shell scripting language as permissions in shell scripts are in the filesystem).

Less social, more technical. Please. Otherwise there is no hope of making things better.

Re: Systemd v228 local root exploit

#123

Post by cestith »

JdeBP wrote: post #110
avian wrote: post #59

Earlier quoted context omitted.

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

van Smoorenburg init dates from 1992. Considering its bug history from age 12 to age 25 and comparing that to systemd's bug history from age 5 to age 6 is at the very best misleading. At age 4, van Smoorenburg init was panicking when /etc/inittab had blank lines. At age 6, van Smoorenburg init was having a buffer overflow in init.c fixed. Counting the CVE bugs is a silly approach. It is far better to look at the codi…

Why is it misleading? Why if we had something safe and stable because of its age and refinement is that an excuse to stuff something less mature in its place?

Personally I like unit files rather than bespoke Bash scripts, I like dependency-driven parallel startup, and I like getting a daemon watchdog for free. That's about where I'd have ended the feature requests, though. I'd also like it to be roughly as secure as what it's replacing.

Re: Systemd v228 local root exploit

#124

Post by rconti »

JdeBP wrote: post #72
jwilk wrote: post #44

Earlier quoted context omitted.

> 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

Well, now I guess I know how I should write SystemD going forward!

Re: Systemd v228 local root exploit

#125

Post by schu »

bkor wrote: post #25
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.

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…

The CVE-HOWTO by RedHat is a good resource to find out about the process:

https://github.com/RedHatProductSecurity/CVE-HOWTO

Re: Systemd v228 local root exploit

#126

Post by ajross »

bandrami wrote: post #113
loeg wrote: post #109

Earlier quoted context omitted.

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.

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

Re: Systemd v228 local root exploit

#127

Post by bandrami »

ajross wrote: post #126
bandrami wrote: post #113

Earlier quoted context omitted.

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.

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

IDK. Slackware isn't noticeably slower to boot than Fedora, at least for me.

Re: Systemd v228 local root exploit

#128

Post by jacobmischka »

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?

Exactly, like the link says, at least it runs without permissions and is sandboxed.

Re: Systemd v228 local root exploit

#129

Post by justinclift »

berdario wrote: post #29
bkor wrote: post #25

Earlier quoted context omitted.

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…

I don't know any insider, but obtaining a CVE was not really difficult: http://seclists.org/oss-sec/2016/q3/231 (and it was not even my project... I just reported the bug) Now the workflow changed a bit, in the link that you shared in fact it says "For open source software products not listed below, request a CVE ID through the Distributed Weakness Filing Project CNA." which is just an easy-to-fill Google form. Not s…

There seems to be a pretty major backlog for getting CVE numbers, such that for not-hugely-impacting ones it seems like the CVE request people won't take any time to discuss things.

Saying that after trying to get a CVE for a low risk problem with CMake on Windows. Applied for a CVE (months ago), and the only response received was:

  Please resend your CVE request properly (the description was not filled out properly) and
  resubmit. The correct format is:

  [Vendor name] [product name] version [version info] is vulnerable to a [single flaw type]
  in the [component] resulting [some impact].
Which is strange. I looked over the original submission, and there's nothing that I'd change in it. Emailed the person back asking for clarification and received zero reply.

If it was a high risk bug, I'd probably take the time to follow up more. Since it's not though... ;D

Re: Systemd v228 local root exploit

#130

Post by Frenchgeek »

x0 wrote: post #14
bergers89 wrote: post #7

yeah, awesome, i enjoy this systemD shit show. Linux is so doomed.

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

But it make for cheap heating at least.
Post reply on HN