[sf-lug] systemd memory corruption...

[Michael Paoli]

P.S.

This might also leave some wondering if I run systemd.
The answer is: Yes, and no.  Or much more specifically:
On some hosts: Yes
On some hosts: ABSOLUTELY HELL F*CKIN' NO DAMN WAY!
It's good to have choices.  Even better within the same distro (Debian!).

> From: "Michael Paoli" <Michael.Paoli at cal.berkeley.edu>
> Subject: Re: [sf-lug] systemd memory corruption...
> Date: Thu, 10 Jan 2019 19:53:29 -0800

>> 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.