101–110 of 162 posts
>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.
Earlier quoted context omitted.
I'd still expect GCC to warn about that
Warn about what? "mode > 0" is not always true.
Earlier quoted context omitted.
This is frequently how the linux kernel operates.
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.
Wow. 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 quer…
Earlier quoted context omitted.
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 works though: $ systemd --version systemd 229
Same on Debian Jessie. EDIT: And on openSUSE Tumbleweed
Earlier quoted context omitted.
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 works though: $ systemd --version systemd 229
systemctl --version on Fedora
Why does systemd have functionality to create files as root for unprivileged users anyway? What's the point?
Earlier quoted context omitted.
I'm not aware of server or desktop OS that isn't generally vulnerable to local DoS.
Qubes OS
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?
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.
Wow. 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 quer…
At age 4, van Smoorenburg init was panicking when /etc/inittab had blank lines. At age 6, van Smoorenburg init was having a buffer overflow in init.c fixed.
Counting the CVE bugs is a silly approach. It is far better to look at the coding practices that are followed in a project. Are APIs designed and implemented consistently? When a functional change is made, is the doco always changed at the same time to match? Are the reasons for seemingly odd things properly recorded for maintenance programmers in the future to read? There are many, far better, questions to ask in place of how many CVE listings something has had in some arbitrary interval in its lifetime.