> 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".
Systemd v228 local root exploit
51–60 of 162 posts
Re: Systemd v228 local root exploit
#52Earlier quoted context omitted.
Yes, 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.
Compare the sizes of community within Chromium/Linux/PostgreSQL. See how much more accent they put on security. Have you seen any fuzzing attempts started around SystemD, for example?
You are making a comment about "The development process [being] too fast and erratic" (it is not). I'm not defending the systemd process, I'm making a point about that.
Then again, if you think "obfuscating the init process" is a valid description of what systemd does per your other comment, I'm having a hard time seeing this as anything other than armchair security expertise...
Re: Systemd v228 local root exploit
#53>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.
I'm not aware of server or desktop OS that isn't generally vulnerable to local DoS.
OT: If you're averaging +24 karma per day from a throwaway account, maybe you don't need a throwaway?
Re: Systemd v228 local root exploit
#54Earlier 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…
I mostly agree, but I meant to direct my previous comment to this:
> silently fixed in the upstream git is not at all an acceptable way to deal with serious security flaws in your product.
I was suggesting that it might not have been silently fixed, and was instead misdiagnosed.
You can see the commit here: https://github.com/systemd/systemd/commit/06eeacb6fe029804f2...
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.
Re: Systemd v228 local root exploit
#55>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.
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.
polkit doesn't typically run on server installations, so this isn't that bad.
Re: Systemd v228 local root exploit
#56Wow. 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.
Re: Systemd v228 local root exploit
#57Earlier quoted context omitted.
Compare the sizes of community within Chromium/Linux/PostgreSQL. See how much more accent they put on security. Have you seen any fuzzing attempts started around SystemD, for example?
You are making a comment about "The development process [being] too fast and erratic" (it is not). I'm not defending the systemd process, I'm making a point about that. Then again, if you think "obfuscating the init process" is a valid description of what systemd does per your other comment, I'm having a hard time seeing this as anything other than armchair security expertise...
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 process - they clearly have no time to refactor, which makes the code have way too little modularity. It's a huge blob linked against libsystemd and fuzzing the components would really be a mess. The project has much too much responsibility, handling parts of system that could easily be delegated to separate projects. It interferes with desktop environments, GNOME being an example.
Re: Systemd v228 local root exploit
#58Re: Systemd v228 local root exploit
#59Wow. 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...
The "sysvinit" binary package has had a total of 2 bug reports tagged "security" filed in Debian's bug tracker. That's over the entire history of the package that goes back to at least 2004.
If I extend the search to all packages built from the "sysvinit" source (which includes packages like initscripts and sysvinit-utils), the count increases to 8.
(source: https://www.debian.org/Bugs. I'm not linking to exact queries since they take quite some time and HN has a tendency of taking down Debian's bug tracker)
Re: Systemd v228 local root exploit
#60Earlier quoted context omitted.
You are making a comment about "The development process [being] too fast and erratic" (it is not). I'm not defending the systemd process, I'm making a point about that. Then again, if you think "obfuscating the init process" is a valid description of what systemd does per your other comment, I'm having a hard time seeing this as anything other than armchair security expertise...
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…
> You just resorted to ad personam for the second time.
...?
I realized my first post was unnecessarily sarcastic and edited that part out. It's hard to comment about your opinions without talking about your opinions.
But okay, you've offered a list, let's go through it:
> Consider logging
Logging is in a binary format, but is more consistently accessible.
> consider a new DSL
In terms of keywords? Do you mean like, which value does what in .service files? That's all extremely well documented. Consider the corresponding init shell scripts, how are they "more transparent" if you have to know shell pretty damn well in order to understand them?
> consider lack of determinism it brings
Now I completely lost you. sysvinit brings far less determinism to the table.
If I found that paragraph in the wild without context I would assume it's about sysvinit.