[sf-lug] systemd memory corruption...

[Ken Shaffer]

...and the patches are out:
systemd (237-3ubuntu10.11) bionic-security; urgency=medium

  * SECURITY UPDATE: memory corruption in journald via attacker controlled
alloca
    - debian/patches/CVE-2018-16864.patch: journald: do not store the iovec
      entry for process commandline on the stack
    - CVE-2018-16864
  * SECURITY UPDATE: memory corruption in journald via attacker controlled
alloca
    - debian/patches/CVE-2018-16865_1.patch: journald: set a limit on the
      number of fields (1k)
    - debian/patches/CVE-2018-16865_2.patch: journal-remote: set a limit on
the
      number of fields in a message
    - CVE-2018-16865
  * SECURITY UPDATE: out-of-bounds read in journald
    - debian/patches/CVE-2018-16866.patch: journal: fix
syslog_parse_identifier()
    - CVE-2018-16866


On Thu, Jan 10, 2019 at 8:30 PM Bobbie Sellers <bliss-sf4ever at dslextreme.com>
wrote:

> 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>
> <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>
> <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/>
> <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.
>
>
>
> _______________________________________________
> sf-lug mailing list
> sf-lug at linuxmafia.com
> http://linuxmafia.com/mailman/listinfo/sf-lug
> Information about SF-LUG is at http://www.sf-lug.org/<br>
> Related Information <br>
> http://www.shallowsky.com/blog/<br>
> http://explainshell.com/ <br>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linuxmafia.com/pipermail/sf-lug/attachments/20190111/b23db865/attachment-0001.html>