It'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.
Systemd v228 local root exploit
21–30 of 162 posts
Re: Systemd v228 local root exploit
#22>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.
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.
Re: Systemd v228 local root exploit
#23>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.
Hanlon's Razor; perhaps whoever wrote/merged the patch didn't consider the possibility of an exploit?
Re: Systemd v228 local root exploit
#24v228 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
Despite 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
systemd 229Re: Systemd v228 local root exploit
#25>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 bugs instead of figuring out if it is a security bug (=method Linus uses).
Re: Systemd v228 local root exploit
#26here's the fix: 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?
Re: Systemd v228 local root exploit
#27>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.
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 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.
Re: Systemd v228 local root exploit
#28Re: Systemd v228 local root exploit
#29>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…
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 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
Re: Systemd v228 local root exploit
#30here's the fix: 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?
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 the other thing is maybe in a safe language you would use an Option/Maybe type here instead of a plain mode_t type.