[sf-lug] systemd and memory corruption...

Bobbie Sellers bliss-sf4ever at dslextreme.com
Thu Jan 24 07:47:26 PST 2019



On 1/22/19 8:35 PM, Rick Moen wrote:
> Quoting Bobbie Sellers (bliss-sf4ever at dslextreme.com):
>
>> Hi LUGers,
>>
>>      Well some of knew in our hearts that systemd was
>> an evil scheme.  ;^)    I found this on the Usenet in a
>> Linux newsgroup, comp.os.linux.misc.  ;^|
>>
>> <https://www.bleepingcomputer.com/news/security/linux-systemd-affected-by-memory-corruption-vulnerabilities-no-patches-yet/>
>>
>>      I haven't had time to read the full article at the site.
>>      Rick can probably comment better than I on the article
>> and its assertions.
> You actually posted the very same story, with the very same URL, on
> January 10th.
         Thanks for the valuable comments.  As to why I re-posted it., 
my attention  often diminishes quite
enough.

     Bobbie Sellers

> At the time, I was, in a brief fit of delirious optimism,
> hoping someone else would make the obvious observation -- that it's
> fundamentally and horribly wrong that it should _ever_ be possible to
> not only send remote network data to a system logger daemon
> (systemd-logind.service) and corrupt memory but also thereby gain remote
> control of a root-user shell.  That whether or not this abject security
> failure got 'fixed' was trivia compared to the vital point that this
> should not have been possible in the first place.
>
> And: nope.
>
> Sure enough, there were a couple of interesting follow-ups, e.g.,
> Michael P. commented on the core systemd init's carefree assumption
> that the running init must be system _without checking_ that this was
> true, leading to 'all hell breaking loose' when the newly arrived
> systemd software shot PID#1 (SysVInit) in the head and took its place
> as PID#1 (grimly amusing to contemplate, albeit ghastly).
>
> The only other comment was Ken Shaffer saying a day later tat Ubuntu had
> security patces out -- but nobody went for the obvious takeaway.
>
> I don't like to harp on that matter, especially if, as seems likely,
> people here really don't want to hear the message, and so phrased it an
> entirely different way, by quoting *ix security expert Marcus Ranum:
>
>
>    One clear symptom that you've got a case of "Penetrate and Patch" is
>    when you find that your system is always vulnerable to the "bug of the
>    week."  It means that you've put yourself in a situation where every time
>    the hackers invent a new weapon, it works against you.  Doesn't that
>    sound dumb?  Your software and systems should be secure by design and
>    should have been designed with flaw-handling in mind.
>                                        -- Marcus J. Ranum
>    http://www.ranum.com/security/computer_security/editorials/dumb/
>
>
>    Patching shows an acceptance that the administrator has not
>    _solved the problem_ - it shows an acceptance that you have signed up
>    for an endless war that you cannot win.  Master Sun might say it
>    indicates you are stupid or, at the very least, hammered into stupidity
>    by the constant stream of vulnerabilities in mission critical-software.
>    It should be pretty obvious that constantly upgrading mission critical
>    software is a _bad_ idea from a systems-reliability standpoint, too.
>                                        -- Marcus J. Ranum
>    http://www.ranum.com/security/computer_security/editorials/master-tzu/
>
>
> Ranum's point (elaborated on at the two links provided) is that, once
> you assess a security-sensitive system as just fundamentally _bad_,
> beset with security bugs that should never have existed at all, it's
> past time to stop 'fixing' that software, and instead get rid of it.
>
> _______________________________________________
> sf-lug mailing list
> sf-lug at linuxmafia.com
> http://linuxmafia.com/mailman/listinfo/sf-lug
> SF-LUG is at http://www.sf-lug.org/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linuxmafia.com/pipermail/sf-lug/attachments/20190124/986c8b8a/attachment.html>


More information about the sf-lug mailing list