Stories
Slash Boxes
Comments

SoylentNews is people

posted by martyb on Friday January 11 2019, @12:54PM   Printer-friendly
from the deep-seated-insecurities-and-paranoia dept.

From TFA (the friendly article) at https://www.openwall.com/lists/oss-security/2019/01/09/3:

We discovered three vulnerabilities in systemd-journald (https://en.wikipedia.org/wiki/Systemd):

- CVE-2018-16864 and CVE-2018-16865, two memory corruptions     (attacker-controlled alloca()s);

- CVE-2018-16866, an information leak (an out-of-bounds read).

CVE-2018-16864 was introduced in April 2013 (systemd v203) and became exploitable in February 2016 (systemd v230). We developed a proof of concept for CVE-2018-16864 that gains eip control on i386.

CVE-2018-16865 was introduced in December 2011 (systemd v38) and became exploitable in April 2013 (systemd v201). CVE-2018-16866 was introduced in June 2015 (systemd v221) and was inadvertently fixed in August 2018.

We developed an exploit for CVE-2018-16865 and CVE-2018-16866 that obtains a local root shell in 10 minutes on i386 and 70 minutes on amd64, on average. We will publish our exploit in the near future.

To the best of our knowledge, all systemd-based Linux distributions are vulnerable, but SUSE Linux Enterprise 15, openSUSE Leap 15.0, and Fedora 28 and 29 are not exploitable because their user space is compiled with GCC's -fstack-clash-protection.

This confirms https://grsecurity.net/an_ancient_kernel_hole_is_not_closed.php: "It should be clear that kernel-only attempts to solve [the Stack Clash] will necessarily always be incomplete, as the real issue lies in the lack of stack probing."

The article goes on with more detailed information on exploits.

<sarcasm>It's a good thing that systemd does not affect very many systems and no systems running anything important.</sarcasm>


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 5, Insightful) by canopic jug on Friday January 11 2019, @02:03PM (4 children)

    by canopic jug (3949) Subscriber Badge on Friday January 11 2019, @02:03PM (#785027) Journal

    The bugs were around for around two years. They're also the result of a combination of known bad design and known bad programming practices. Mistakes cannot be avoided but bad design and bad practices can. Those alone are enough reason to eschew garbage like systemd. On top of that you have an enormous monolith of complex, sparsely documented code.

    --
    Money is not free speech. Elections should not be auctions.
    Starting Score:    1  point
    Moderation   +4  
       Insightful=3, Touché=1, Total=4
    Extra 'Insightful' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   5  
  • (Score: 5, Insightful) by digitalaudiorock on Friday January 11 2019, @02:24PM

    by digitalaudiorock (688) on Friday January 11 2019, @02:24PM (#785032) Journal

    Never mind that these bugs are in their shit-for-brains systemd-journald and binary logging. None of that should have ever happened, and nobody with any sense wanted it. But yea...it's all good...as long as sysadmins whose companies fell for RHEL 7 start treating it the way they've treated Windows Server...which is about where this has gone. Good luck with all that. No systemd in my home or my company, and never will be...thank God.

  • (Score: 4, Interesting) by Thexalon on Friday January 11 2019, @08:20PM (2 children)

    by Thexalon (636) on Friday January 11 2019, @08:20PM (#785205)

    Also, can we stop letting Lennart be in charge of anything important, please? Between systemd's awfulness (including on occasion breaking the Linux kernel) and PulseAudio's awfulness (ditto), I'm trying to figure out why anyone thinks he should be doing coding without adult supervision.

    The moment I knew how bad systemd truly was: shortly after I had installed it for the first time on a desktop, I decided to swap out my aging PS/2 mouse for a USB mouse, so I shut down the machine, switched the mice, turned it back on, and was greeted with a black screen with no feedback at all about what was going on, and nothing in the logs about what had gone wrong when I swapped the mice back. Whereas my sysvinit-based system, in the same situation, would have booted up just fine and at worst would have needed some config file changed and a relevant daemon restarted. Based on that, I was forced to conclude that either the systemd developers had either not even thought about the possibility of swapping out hardware while the machine was turned off, or didn't care enough of about that scenario to make their stuff work properly under those conditions.

    --
    The only thing that stops a bad guy with a compiler is a good guy with a compiler.
    • (Score: 2, Funny) by Anonymous Coward on Saturday January 12 2019, @11:48AM (1 child)

      by Anonymous Coward on Saturday January 12 2019, @11:48AM (#785469)

      Thank you for your bug report. We here at systemD central think that you are a poopy head with a need for a brain swap.
      Please soak your head in vinegar.
      And Have A Nice Day.

      • (Score: 2) by Thexalon on Sunday January 13 2019, @03:01PM

        by Thexalon (636) on Sunday January 13 2019, @03:01PM (#785908)

        You forgot to mark it as "WONTFIX".

        --
        The only thing that stops a bad guy with a compiler is a good guy with a compiler.