28 ms·
Systemd v228 local root exploit
- kogepathic 10y ago> "new services as a service" Accurately describes systemd's development over the past few years.
- digi_owl 10y agoSurprise surprise...
- oblio 10y ago(Future readers can safely ignore the rest of the comment, I was struck by the "did not read the article" disease) Surprised that software has security flaws? Especially software written in "let-me-use-that-chainsaw-to-trim-the-bushes" C? :) I know that there will be security flaws in any language, but if there ever was software today that deserved a safer programming language, the init system was it. Or the web browser.
- lclarkmichalek 10y agoYeah this issue really has nothing to do with C
- mfukar 10y agoIt's not the logic of hammering my own fingers that is flawed, it is my choice of a hammer!
- adrianN 10y agoYou can program touch() to create files with 0777 rights in any language, not just C.
- throwawayish 10y agoAlthough 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.
- kps 10y agoIt'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/06eeacb6fe029804f296b065b3ce91e796e1cd0e https://github.com/systemd/systemd/commit/06eeacb6fe029804f2...
- mfukar 10y agoIsn't that what I said?
- theamk 10y agoYes, but other languages would use optional or special null-like value which cannot be automatically converted into integer.
- josteink 10y ago> Surprise surprise... About as surprising as seeing completely content-less anti-systemd comments like yours popping up, really.
- implr 10y ago>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.
- galapago 10y ago> they also seem to think that a local DoS is not enough for a CVE Some vendors do not consider local DoS as security issues. I tried to discuss these kind of issues in oss-security but even MITRE refused to assign a CVE.
- belorn 10y agoIf the system are not restricted by having quota on every computer resource its trivial for any local user to DoS the system. For the issue to be exploitable, you need to have restrictions in place and to my knowledge the only way to do so in the past was with seLinux. Today of course there is cgroup.
- kseifried 10y agoWhich one was this specifically? Not all local DoS's are security vulnerabilities, in general there needs to be a trust boundary that is violated, e.g. the ping of death, clearly a single remote ICMP packet shouldn't cause the system to reboot. But what about DoS's that can only be triggered by root? And the whole grey area in between these two extremes?
- galapago 10y agoIt was a trivial DoS using a SVG file in a browser. After a a minute, it consumes most of the memory available.
- throwawayish 10y agoI'm not aware of server or desktop OS that isn't generally vulnerable to local DoS.
- etatoby 10y agoWho would have thought.
- bergers89 10y agoyeah, awesome, i enjoy this systemD shit show. Linux is so doomed.
- x0 10y agoYou'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
- lclarkmichalek 10y agoI think the headphone jack lava is more a pulseaudio bug
- deleted 10y ago[deleted]
- sirmac1k 10y agoI personally vote for it as a feature, makes nice effect on my desk. Little WOW effect for colleagues.
- efaref 10y agoThe reason for Apple removing the headphone jack is finally revealed!
- d33 10y agoYou don't really need jets of lava to have a catastrophe. Also, it doesn't have to happen right away - OpenSSL was neglected for years before heartbleed happened. Also, keep in mind that it only takes one vuln to compromise the system and we're definitely hearing of too many of them throughout the time. It is NOT a secure project. It's not even remotely so. The development process is too fast and erratic.
- scrollaway 10y agoYes, tell us all you know about the systemd development process. And while you're at it, enlighten us all about how the it is "too fast"; average citizens like myself see but a pace far slower than those other "NOT secure projects" Chromium, Linux and Postgres.
- belorn 10y agov228 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.
- lclarkmichalek 10y agoIf 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
- mhotchen 10y agoDespite being in the man page, the flag --version didn't work for me on Ubuntu 16.04 (various different installations): $ init --version init: unrecognised option '--version' systemd --version works though: $ systemd --version systemd 229
- Esau 10y agoIt'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.
- d33 10y ago:D I know you're joking, but it's a nice way to say what they basically do. EDIT: I elaborated here: https://news.ycombinator.com/item?id=13470953 https://news.ycombinator.com/item?id=13470953
- jwilk 10y ago> SystemD https://lists.debian.org/878ttl9go6.fsf@hope.eyrie.org https://lists.debian.org/878ttl9go6.fsf@hope.eyrie.org
- baq 10y agohere's the fix: https://github.com/systemd/systemd/commit/06eeacb6fe029804f296b065b3ce91e796e1cd0e 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?
- benmmurphy 10y ago2) 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 < 0. though, maybe safe languages will let you do this explicit cast as well so maybe they won't save you. the other thing is maybe in a safe language you would use an Option/Maybe type here instead of a plain mode_t type.
- lmm 10y ago> maybe safe languages will let you do this explicit cast as well They will let you, but explicit casts are a red flag in code review.
- tveita 10y agoSo in other words it wouldn't have made a difference. A better type system gives you the option to enforce stricter checks to help you catch mistakes, but the same people with the same procedures would have written this bug in any language.
- lmm 10y agoNot 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.
- qwertyuiop924 10y agoWow. 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...
- jsjsjsjsjsjs 10y agoI 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.
- bkor 10y agoIMO 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.
- qwertyuiop924 10y agoWell, if dull rock can't be exploited, maybe we should be putting dull rock in PID1?
- MertsA 10y agoThis exploit isn't in PID 1 and neither are all of the other things people claim are in PID1. PID1 in systemd doesn't contain much more than it needs to, it handles parsing unit files which could arguably be split out but that still leaves something highly privileged to parse them, but just about everything else would be a major pain to separate from PID 1 as most of it is how to walk the dependency graph from where it currently is to the target that it's trying to get to. It also needs to handle supervision and other core parts of init but by and large most of the claims out there that everything and the kitchen sink is being put into PID 1 are completely baseless.
- zakk 10y ago> mode_t is unsigned, so MODE_INVALID < 0 can never be true. Wouldn't GCC complain about a comparison which is always true?
- dijit 10y agoI do not doubt that issues like this will become more common in future. Code quality/clarity is nearing that of OpenSSL.
- tinus_hn 10y agoWhy does systemd have functionality to create files as root for unprivileged users anyway? What's the point?
- djsumdog 10y agoI 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/ee735086f8670be1591fa9593e80dd60163a7a2f/src/basic/fs-util.c https://github.com/systemd/systemd/blob/ee735086f8670be1591f... ..and most init systems do have a legitimate use case for touching a file.
- bandrami 10y agoIf only UNIX provided an existing utility to do that...
- xena 10y agoSo you want pid1 constantly calling out to userland binaries to do basic filesystem manipulation tasks?
- bandrami 10y agoWell, 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?
- bonzini 10y agoWhat's the advantage of such an architecture?
- bandrami 10y agoThe advantage is that the kernel panics if PID 1 ever crashes, so I want PID 1 never to crash or even be able to crash. It also means I want the binary to have as little of an attack surface as possible, and particularly I don't want it listening to dbus or having links to a QR generation library. This is a solved problem with multiple good solutions [1] [2] [3], so I can easily avoid those issues by not using systemd. [1] http://www.gnu.org.ua/software/pies/ http://www.gnu.org.ua/software/pies/ [2] http://universe2.us/epoch.html http://universe2.us/epoch.html [3] http://core.suckless.org/sinit http://core.suckless.org/sinit
- bandrami 10y agoWhy 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?
- loeg 10y agoFork 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.
- bandrami 10y agoSure, 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.
- ajross 10y ago> 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.
- bandrami 10y agoIDK. Slackware isn't noticeably slower to boot than Fedora, at least for me.
- JdeBP 10y ago> 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://uselessd.darknedgy.net./ProSystemdAntiSystemd/ * http://blog.darknedgy.net/technology/2015/09/05/0/ http://blog.darknedgy.net/technology/2015/09/05/0/
- api 10y agoLocal 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.
- mangix 10y agoFun fact: the person who fixed this is an Arch Linux developer. The whole issue based on the commit seems like an oversight (thinking mode_t is signed). This doesn't appear to be malicious in any way. Note that many apps have sign issues like these, with the difference being that it's not enough to give root.