<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:large">...and the patches are out:</div><div class="gmail_default" style="font-size:large">systemd (237-3ubuntu10.11) bionic-security; urgency=medium<br><br>  * SECURITY UPDATE: memory corruption in journald via attacker controlled alloca<br>    - debian/patches/CVE-2018-16864.patch: journald: do not store the iovec<br>      entry for process commandline on the stack<br>    - CVE-2018-16864<br>  * SECURITY UPDATE: memory corruption in journald via attacker controlled alloca<br>    - debian/patches/CVE-2018-16865_1.patch: journald: set a limit on the<br>      number of fields (1k)<br>    - debian/patches/CVE-2018-16865_2.patch: journal-remote: set a limit on the<br>      number of fields in a message<br>    - CVE-2018-16865<br>  * SECURITY UPDATE: out-of-bounds read in journald<br>    - debian/patches/CVE-2018-16866.patch: journal: fix syslog_parse_identifier()<br>    - CVE-2018-16866<br><br></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Jan 10, 2019 at 8:30 PM Bobbie Sellers <<a href="mailto:bliss-sf4ever@dslextreme.com">bliss-sf4ever@dslextreme.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  
    
  
  <div bgcolor="#FFCCFF">
    <font size="+2"><font face="Tahoma">Hi LUGers,<br>
      </font></font><font face="Tahoma">    Some live distros use it and
      there I have had <br>
      no problems.<br>
       </font>   But for this user I am very happy that PCLinuxOS64 is
    free of systemd<font face="Tahoma"><b>,<br>
         </b></font>and I had problems on another system that used
    systemd<font face="Tahoma"><b>,</b> but that<br>
      was installed to my hard drive.  Maybe someday I will have to use
      it and<br>
       by that time i hope it has been properly debugged.<br>
          So the answer for me is like that of Michael, yes and no.<br>
          bliss<br>
    </font><br>
    <div class="gmail-m_5384721602057381214moz-cite-prefix">On 1/10/19 8:01 PM, Michael Paoli
      wrote:<br>
    </div>
    <blockquote type="cite">P.S.
      <br>
      <br>
      This might also leave some wondering if I run systemd.
      <br>
      The answer is: Yes, and no.  Or much more specifically:
      <br>
      On some hosts: Yes
      <br>
      On some hosts: ABSOLUTELY HELL F*CKIN' NO DAMN WAY!
      <br>
      It's good to have choices.  Even better within the same distro
      (Debian!).
      <br>
      <br>
      <blockquote type="cite">From: "Michael Paoli"
        <a class="gmail-m_5384721602057381214moz-txt-link-rfc2396E" href="mailto:Michael.Paoli@cal.berkeley.edu" target="_blank"><Michael.Paoli@cal.berkeley.edu></a>
        <br>
        Subject: Re: [sf-lug] systemd memory corruption...
        <br>
        Date: Thu, 10 Jan 2019 19:53:29 -0800
        <br>
      </blockquote>
      <br>
      <blockquote type="cite">
        <blockquote type="cite">From: "Bobbie Sellers"
          <a class="gmail-m_5384721602057381214moz-txt-link-rfc2396E" href="mailto:bliss-sf4ever@dslextreme.com" target="_blank"><bliss-sf4ever@dslextreme.com></a>
          <br>
          Subject: [sf-lug] systemd memory corruption...
          <br>
          Date: Thu, 10 Jan 2019 13:41:09 -0800
          <br>
        </blockquote>
        <br>
        <blockquote type="cite">    Not necessary but present in some
          systems.
          <br>
              Read about it below.
          <br>
<a class="gmail-m_5384721602057381214moz-txt-link-rfc2396E" href="https://www.bleepingcomputer.com/news/security/linux-systemd-affected-by-memory-corruption-vulnerabilities-no-patches-yet/" target="_blank"><https://www.bleepingcomputer.com/news/security/linux-systemd-affected-by-memory-corruption-vulnerabilities-no-patches-yet/></a>
          <br>
        </blockquote>
        <br>
        Sounds like bug / security vulnerabilities in systemd ... at
        least one of
        <br>
        which is network exploitable (whee!).  Yep, make systemd
        permeate
        <br>
        everything, always running with all privileges, that way if
        there's a
        <br>
        bug most anywhere, why let it be a mere bug when we can have it
        <br>
        instead be a remote root exploit!  Uhm, yeah, about that ...
        <br>
        <br>
        Interesting bit though, ... you know, kernel updates,
        <br>
        need to reboot to get the benefits (e.g. security fixes) of the
        <br>
        new kernel, ... same for the init system, ... right? ... right?
        <br>
        <br>
        Well, for better and/or worse, systemd has a neat trick it can
        do.
        <br>
        I can replace itself while it's running ... so yes, one can
        patch/upgrade
        <br>
        the systemd init system(!) while it's running, and reap at least
        some of
        <br>
        those benefits (maybe all of them - depending how fully it
        replaces any
        <br>
        and all pieces that were running or still resident anywhere in
        RAM for
        <br>
        such, etc.).
        <br>
        <br>
        The first time I learned of this ... uhm, yeah, ... a very ugly
        mess had
        <br>
        systemd created in its overzealous attempt at such.  See, I was
        running
        <br>
        Debian stable (or at least it was the stable then), had fairly
        recently
        <br>
        upgraded to stable.  But systemd had given me lots of grief, so
        I was like
        <br>
        screw that, boot ye olde init system (still all there).  That
        was all fine
        <br>
        and dandy until ... regular security, etc. updates.  Included
        update(s)
        <br>
        to systemd.  Well, even though the running init system wasn't
        systemd,
        <br>
        systemd, in its overzealous stupidity, in having its software
        updated,
        <br>
        would go and replace the running init (PID 1) with itself ...
        and most
        <br>
        unfortunately, it didn't even bother to check what init system
        was
        <br>
        currently running.  So, ... I had a host running sysvinit, where
        <br>
        upgrade of a systemd package caused it to have the unconcerned
        brazenness
        <br>
        to replace the running PID 1 without bothering to even determine
        if it
        <br>
        was systemd.  Of course once that happened all hell broke loose
        immediately.
        <br>
        Yes, that earned systemd a much more disabled configuration - so
        it would
        <br>
        not make such stupid presumptions again ... nor would it have
        enough
        <br>
        presence or power to even successfully make any such overbearing
        attempt.
        <br>
      </blockquote>
      <br>
    </blockquote>
    <br>
  </div>

_______________________________________________<br>
sf-lug mailing list<br>
<a href="mailto:sf-lug@linuxmafia.com" target="_blank">sf-lug@linuxmafia.com</a><br>
<a href="http://linuxmafia.com/mailman/listinfo/sf-lug" rel="noreferrer" target="_blank">http://linuxmafia.com/mailman/listinfo/sf-lug</a><br>
Information about SF-LUG is at <a href="http://www.sf-lug.org/" rel="noreferrer" target="_blank">http://www.sf-lug.org/</a><br><br>
Related Information <br><br>
<a href="http://www.shallowsky.com/blog/" rel="noreferrer" target="_blank">http://www.shallowsky.com/blog/</a><br><br>
<a href="http://explainshell.com/" rel="noreferrer" target="_blank">http://explainshell.com/</a> <br></blockquote></div>