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.
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 bugs instead of figuring out if it is a security bug (=method Linus uses).
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 such a close system as you seem to imply
(OTOH, obviously CVE cannot guarantee or pretend to have universal coverage of every security issue ever existed)
I generally like systemd, but it's irresponsible to not publicly communicate about such an issue if you're aware that it's actually a security issue
fix bugs before investigating, that's ok... but not communicating it means that you'll leave users downstream exposed to it, since it won't prompt maintainers to ship the patch/upgrade
My goal long term is to have CVE requests take <5 minutes for the requestor and <1 minute for the assigner to process. We need to scale this out and simplify it vastly. People need to be aware of security flaws so they can be dealt with, and CVE is the best option for this we have currently.
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 with the no-CVE issue from above it makes it even worse.
When systemd is taking over more and more critical parts of the system, and getting deployed to most linux distros, it's only fair that we expect more of them and put them under more scrutiny. That they trip on such a "trivial" case is kind of scary.
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.
This was the response: https://lists.freedesktop.org/archives/systemd-devel/2016-De...
systemd is a bomb waiting to go off, IMHO.
There are much simpler solutions without setuid: https://skarnet.org/software/s6/s6-sudo.html.
I honestly do not understand how you can feel comfortable making judgement calls about projects when you cannot even accurately state their function.
https://github.com/systemd/systemd/blob/ee735086f8670be1591f...
..and most init systems do have a legitimate use case for touching a file.
Can you name such a legitimate use case then? All I can think of is the need to write a pid file, and pid files are a kludge that real service supervisors gladly do away with.
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) are:
* timestamp files for timer units
* device tags files in systemd-udev
* /run/udev/queue
* timestamp files used by timesyncd
* private devices, bind mounts, and mirrored /etc/resolv.conf created by systemd-nspawn
* "linger" flags used by systemd-logind
* temporary files used by "systemctl edit"
* All sorts of flag files: /run/systemd/journal/flushed , /run/systemd/quotacheck , /run/systemd/show-status , /run/systemd/first-boot
* 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
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?
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.
The fchown() system call supports passing -1, cast to the appropriate type, as a no-op value. The systemd people were attempting to wrap similar semantics around fchmod(). Originally in 2014 M. Sievers specified (mode_t)0 as the no-op value, which wasn't a good choice, with M. Poettering changing it to (mode_t)-1 in 2015 but overlooking one place where the value remained tested against 0.
* https://github.com/systemd/systemd/commit/c38dfac9ed6c1c3beb...
So it would become something like `mode.unwrap_or(0o644)` which doesn't leave a lot of room for error.
They will let you, but explicit casts are a red flag in code review.
Ubuntu never ran with such early version, since their first uploaded version was 229.
$ init --version
systemd 231
+PAM +AUDIT +SELINUX +IMA -APPARMOR +SMACK -SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT -GNUTLS -ACL +XZ -LZ4 +SECCOMP +BLKID -ELFUTILS +KMOD -IDN $ init --version
init: unrecognised option '--version'
$ systemd --version
systemd 229The best command to invoke here is either "systemctl" or "systemd".
* https://lists.debian.org/debian-devel/2016/08/msg00547.html
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
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.
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.
Wouldn't GCC complain about a comparison which is always true?
Accurately describes systemd's development over the past few years.
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.
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.