[sf-lug] systemd memory corruption...

[Bobbie Sellers]

Hi LUGers,
     Some live distros use it and there I have had
no problems.
    But for this user I am very happy that PCLinuxOS64 is free of systemd*,
*and I had problems on another system that used systemd*,* but that
was installed to my hard drive.  Maybe someday I will have to use it and
  by that time i hope it has been properly debugged.
     So the answer for me is like that of Michael, yes and no.
     bliss

On 1/10/19 8:01 PM, Michael Paoli wrote:
> 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.
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linuxmafia.com/pipermail/sf-lug/attachments/20190110/06085bec/attachment-0001.html>