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.
Just to be clear, systemd is not part of the Linux kernel.
Also, if you are going to make a broad claim like that I would appreciate some citations/examples. I have no idea if you are wrong or right on the whole, but without examples I can't learn myself.
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).
(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
If you go to https://cve.mitre.org/ it has a link "Request a
CVE ID" which IMO explains that it is only for some products, not all. Alternatively there's also a weblink below it which want GPG key, etc. Alternatively you can email some mailing list, but I don't see where this is documented.
The complaint was that the CVE should've 1) been included in the commit 2) been made. IMO the entire thing is confusing.
Also like to repeat: it's super nice that things are reported and have a CVE. But that doesn't mean every security commit will be seen as related to security.
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
That is not true anymore. You can get a CVE from MITRE for anything (they are the ultimate root authority), and for the Open Source world you can get a CVE from the DWF (https://distributedweaknessfiling.org ), something that is currently slow because we're working on automating a lot of it and stream lining the process (I'll be giving a talk on this at RSA: Saving CVE with OpenSource: https://www.rsaconference.com/events/us17/agenda/sessions/56... ).
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.
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.
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 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.
Now I'm not sure if this was linked to a pull request or some other place where discussion took place, but it looks like it was a simple fix, by one person, over a year ago.
At a minimum I think this suggests that more scrutiny is required, especially for bugs that suggest security issues.
> 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.
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.
> 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.
If 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.
Which 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?
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.
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.
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 polkit and dbus permissions. This makes it really hard to look at something and know what it can do. For example steam, when you start it up, asks NetworkManager to bring up an internet connection. To disable that one has to write javascript.
In short, it's a clusterfuck. Even if everything worked properly (that is hard with Turing complete configuration files) it is still too vague, too big of a load to administrate. I expect the fd.o/fedora peoples answer to that (when people start complaining, that is) to be a GUI, not a rewrite.
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 :)
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.
Well, since this was the recommendation from one of the polkit contributors... I'm not exactly sure what you mean. Perhaps you can enlighten me with your wisdom.
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.
As a Qubes user, no, not at all. It's fairly easy to starve other VMs of resources. Qubes is more vulnerable here than other systems, due to it's dynamic allocation of memory. A VM that has a no-matter-what fixed limit of say 2 GB RAM would have a harder time to cause trouble there, but the dynamic management done by Qubes is a major selling point, otherwise it wouldn't be really practical to use on mobile hardware (which is all the rage). I believe one can disable it on a per-VM basis though, so there's that.
Given how furiously the thought police react to an OT comment, or indeed any comment mentioning karma, I should have created a throwaway for that question... -4 jeez
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.
Why 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?
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.
Poeterring works for Red Hat and it was written on Fedora. Yes, Ubuntu had something else. I don't see how that's relevant to a discussion of systemd's design goals.
Fun 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.
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".
2) 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.
It wasn't really anything to do with the language, and far more to do with the operating system kernel API.
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.
The same error could technically occur in Rust if the API was designed that way but I think the "Rust way" would mandate using an `Option` instead of a special MODE_INVALID value.
So it would become something like `mode.unwrap_or(0o644)` which doesn't leave a lot of room for error.
So 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.
Not 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.
Eh, I feel like I've seen even pickier static analysis warnings. If the next -Wall told me I should rewrite this as "mode != 0" to confirm the intent, that wouldn't seem crazy to me.
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.
Well, 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?
systemd does not have such functionality. You have not read the headlined message correctly.
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
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.