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

81–90 of 162 posts

Re: Systemd v228 local root exploit

#81

Post by JdeBP »

lclarkmichalek wrote: post #18
belorn wrote: post #12

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.

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

On a systemd operating system there may or may not be a program called "init" and it may or may not be an alias for a systemd program. (One's operating system could be one of the ones that just invokes "/lib/systemd/systemd" directly without an "init" at all; or "init" could be Upstart or van Smoorenburg init or the nosh system manager; and of course just running unadorned "init" assumes that "/sbin" is on an unprivileged user's PATH.)

The best command to invoke here is either "systemctl" or "systemd".

Re: Systemd v228 local root exploit

#82

Post by kps »

throwawayish wrote: post #17
adrianN wrote: post #13

Earlier quoted context omitted.

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

Although the specific cause -- (mode_t)-1 -- is something that you can't really do in many languages. So you'd likely have to write 0777 or equivalent explicitly down, making it so much more obvious what a bad idea that is.

It's one part of a cascade of errors. The author(s) defined an opaque MODE_INVALID but wrote code depending on their 'knowledge' of its underlying value. Signed/unsigned confusion is typical of C, though.

The 'fixed' code¹ has the property that calling it to create a file with mode==0 (i.e. no permissions) actually creates one with mode==0644 (i.e. some permissions), which is a wtf r u doin that can't be blamed on C.

¹ https://github.com/systemd/systemd/commit/06eeacb6fe029804f2...

Re: Systemd v228 local root exploit

#83

Post by bkor »

jsjsjsjsjsjs wrote: post #56
qwertyuiop924 wrote: post #46

Wow. That's, let's see... Two exploits over the course of about a year? Hey, I wonder what security problems OpenRC, sysvinit, and bsdinit have had in that time? Food for thought...

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.

IMO having a security bug in systemd is not acceptable. Commits should be carefully reviewed. That other projects (even if these include very important ones) have way more is "meh".

From what I understood from the systemd code is that it's written pretty defensively. I quite like systemd because its useful, thought out, etc. But then I want all that without any drawbacks (because why not!). Probably unrealistic, but nice to strive for a perfect project.

Re: Systemd v228 local root exploit

#84

Post by zokier »

twoodfin wrote: post #51
zakk wrote: post #48

> mode_t is unsigned, so MODE_INVALID Wouldn't GCC complain about a comparison which is always true?

benmmurphy's comment below points out that the flawed test was "mode > 0". https://news.ycombinator.com/item?id=13470516

I'd still expect GCC to warn about that

Re: Systemd v228 local root exploit

#85

Post by geofft »

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…

You need to be an invited project to be able to allocate CVEs out of a block, but you can absolutely request CVEs from one of the participating projects (including MITRE themselves) as a random person. See https://cve.mitre.org/cve/request_id.html . Contacting one of the large OSS product security teams like Red Hat's is also a fine option.

Re: Systemd v228 local root exploit

#86

Post by geofft »

crest wrote: post #79
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.

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

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.

Re: Systemd v228 local root exploit

#87

Post by digi_owl »

bkor wrote: post #80
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…

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

Ah, hello Gnome's roving PR guy...

Re: Systemd v228 local root exploit

#88

Post by geofft »

nolok wrote: post #27
jsmeaton wrote: post #23

Earlier quoted context omitted.

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

I'm not the one who downvoted you, but there is two reasons why this is not a sufficient explanation: 1. That's why you should assign a CVE even for "lower" exploit. This way, people who work in that field look at it and can figure out it's worse when it is. 2. That is still a terrible mark on systemd's procedures that such a thing is not reviewed by someone who will consider an exploit through all lenses, and added…

> 1. That's why you should assign a CVE even for "lower" exploit. This way, people who work in that field look at it and can figure out it's worse when it is.

This isn't reliable; exploits aren't obvious. https://www.usenix.org/legacy/event/hotos09/tech/full_papers...

Within a few hours of review of the bug-fix patches affecting Linux kernel version 2.6.24, we identified a commit from February 2008 with serious security consequences (Git ID 7e3c396, commit subject ``sys_remap_file_pages: fix ->vm_file accounting''). At the time that we conducted this review, this bug and its corresponding patch had been disclosed for more than 10 months, yet it had no associated CVE number or record of any security consequences.

We developed a privilege escalation exploit for this bug in a few hours; doing so did not require any innovative techniques or extensive expertise. The exploit allows any user on a vulnerable system to gain full administrator privileges on the system.

If you care about security, you should run the latest version of all the security-critical software you run. Healthy projects clean up bad / smelly code all the time, and don't investigate the security weaknesses of old versions of their code.

Re: Systemd v228 local root exploit

#89

Post by sounds »

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.

It is not done silently - lack of a public announcement is not the same thing as radio silence. (For CVEs affecting the linux kernel)

Re: Systemd v228 local root exploit

#90

Post by bandrami »

geofft wrote: post #88
nolok wrote: post #27

Earlier quoted context omitted.

I'm not the one who downvoted you, but there is two reasons why this is not a sufficient explanation: 1. That's why you should assign a CVE even for "lower" exploit. This way, people who work in that field look at it and can figure out it's worse when it is. 2. That is still a terrible mark on systemd's procedures that such a thing is not reviewed by someone who will consider an exploit through all lenses, and added…

> 1. That's why you should assign a CVE even for "lower" exploit. This way, people who work in that field look at it and can figure out it's worse when it is. This isn't reliable; exploits aren't obvious. https://www.usenix.org/legacy/event/hotos09/tech/full_papers... Within a few hours of review of the bug-fix patches affecting Linux kernel version 2.6.24, we identified a commit from February 2008 with serious secur…

If you care about security, you should run the latest version of all the security-critical software you run

Well, pick your poison: the latest version also introduces new vulnerabilities. Lenny users managed to miss out on Heartbleed entirely, for instance.

Post reply on HN