Tweet
Count the vulnerabilities affecting BASH shell over recent years
-
-
... and, by keeping in mind that systemd (the init) has much much lower attack surface, try to speculate on how much vulnerabilities it can have.Originally posted by aht0 View Post
Comment
-
half-finished post..Originally posted by starshipeleven View Post
First, mr.Starshipeleven. Please kindly refrain from insults. I might very well be older than you. For second, it's ironic that you are the guy who made me a remark about basic courtesy in another thread, himself throws "idiots" and "punks" non-stop when someone dares to argue your precious worldview. I did not bother mentioning the hyporcrisy of it then, but I will do so now. Does insults make seem your arguments stronger somehow?
About shells and difference in Linux vs BSD code quality.. Try to apply plain common sense God gave baby duck making conclusions by comparing different development philosophies. Fast bleeding edge or conservative. Or if you want to be nitpicker, compare CVE data.
a)CVE's related to Linux kernel security vulnerabilities. 100+ this year a alone.
vs 6 this year.
"total" amount of vulnerabilities in FreeBSD is also multiple times smaller than Linux kernel not even counting the Linux userland in.. I also compared against US National Threat Database CVE total records (506 FreeBSD vs 4829 Linux) of which FreeBSD's all most recent vulnerabilities have already been long fixed)
b)BSD's are not using bash shell, it's either tcsh (FreeBSD) or ksh (OpenBSD) by default. I went trough various existing exploits in internet and latest I could find for FreeBSD shell was targeted for version 8.1 (EOL longtime), back in 2011.
No bash in OS is reason why none of the infamous Shell Shock vulnerabilities affected servers running BSD were none of them is needing bash.
No Glibc in OS was another reason why again, GHOST passed BSD family utterly unnoticed.. "shell script" attack surface may be smaller, but other attack surfaces have increased, including glibc..
About smaller attack surface of systemd..
The first big problem: PID 1
On unix systems, PID 1 is special. Orphaned processes (including a special case: daemons which orphan themselves) get reparented to PID 1. There are also some special signal semantics with respect to PID 1, and perhaps most importantly, if PID 1 crashes or exits, the whole system goes down (kernel panic).
Among the reasons systemd wants/needs to run as PID 1 is getting parenthood of badly-behaved daemons that orphan themselves, preventing their immediate parent from knowing their PID to signal or wait on them.
Unfortunately, it also gets the other properties, including bringing down the whole system when it crashes. This matters because systemd is complex. A lot more complex than traditional init systems. When I say complex, I don't mean in a lines-of-code sense. I mean in terms of the possible inputs and code paths that may be activated at runtime. While legacy init systems basically deal with no inputs except SIGCHLD from orphaned processes exiting and manual runlevel changes performed by the administrator, systemd deals with all sorts of inputs, including device insertion and removal, changes to mount points and watched points in the filesystem, and even a public DBus-based API. These in turn entail resource allocation, file parsing, message parsing, string handling, and so on. This brings us to: The second big problem: Attack Surface
On a hardened system without systemd, you have at most one root-privileged process with any exposed surface: sshd. Everything else is either running as unprivileged users or does not have any channel for providing it input except local input from root. Using systemd then more than doubles the attack surface.
This increased and unreasonable risk is not inherent to systemd's goal of fixing legacy init. However it is inherent to the systemd design philosophy of putting everything into the init process.Comment
Comment