[sf-lug] systemd memory corruption...

[Michael Paoli]

> From: "Bobbie Sellers" <bliss-sf4ever at dslextreme.com>
> Subject: [sf-lug] systemd memory corruption...
> Date: Thu, 10 Jan 2019 13:41:09 -0800

>     Not necessary but present in some systems.
>     Read about it below.
> <https://www.bleepingcomputer.com/news/security/linux-systemd-affected-by-memory-corruption-vulnerabilities-no-patches-yet/>

Sounds like bug / security vulnerabilities in systemd ... at least one of
which is network exploitable (whee!).  Yep, make systemd permeate
everything, always running with all privileges, that way if there's a
bug most anywhere, why let it be a mere bug when we can have it
instead be a remote root exploit!  Uhm, yeah, about that ...

Interesting bit though, ... you know, kernel updates,
need to reboot to get the benefits (e.g. security fixes) of the
new kernel, ... same for the init system, ... right? ... right?

Well, for better and/or worse, systemd has a neat trick it can do.
I can replace itself while it's running ... so yes, one can patch/upgrade
the systemd init system(!) while it's running, and reap at least some of
those benefits (maybe all of them - depending how fully it replaces any
and all pieces that were running or still resident anywhere in RAM for
such, etc.).

The first time I learned of this ... uhm, yeah, ... a very ugly mess had
systemd created in its overzealous attempt at such.  See, I was running
Debian stable (or at least it was the stable then), had fairly recently
upgraded to stable.  But systemd had given me lots of grief, so I was like
screw that, boot ye olde init system (still all there).  That was all fine
and dandy until ... regular security, etc. updates.  Included update(s)
to systemd.  Well, even though the running init system wasn't systemd,
systemd, in its overzealous stupidity, in having its software updated,
would go and replace the running init (PID 1) with itself ... and most
unfortunately, it didn't even bother to check what init system was
currently running.  So, ... I had a host running sysvinit, where
upgrade of a systemd package caused it to have the unconcerned brazenness
to replace the running PID 1 without bothering to even determine if it
was systemd.  Of course once that happened all hell broke loose immediately.
Yes, that earned systemd a much more disabled configuration - so it would
not make such stupid presumptions again ... nor would it have enough
presence or power to even successfully make any such overbearing attempt.