Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Security Linux

Linux systemd Affected by Memory Corruption Vulnerabilities, No Patches Yet (bleepingcomputer.com) 306

Posted by msmash from the call-the-IT dept.
Major Linux distributions are vulnerable to three bugs in systemd, a Linux initialization system and service manager in widespread use, California-based security company Qualys said late yesterday. From a report: The bugs exist in 'journald' service, tasked with collecting and storing log data, and they can be exploited to obtain root privileges on the target machine or to leak information. No patches exist at the moment. Discovered by researchers at Qualys, the flaws are two memory corruption vulnerabilities (stack buffer overflow - CVE-2018-16864, and allocation of memory without limits - CVE-2018-16865) and one out-of-bounds error (CVE-2018-16866). They were able to obtain local root shell on both x86 and x64 machines by exploiting CVE-2018-16865 and CVE-2018-16866. The exploit worked faster on the x86 platform, achieving its purpose in ten minutes; on x64, though, the exploit took 70 minutes to complete. Qualys is planning on publishing the proof-of-concept exploit code in the near future, but they did provide details on how they were able to take advantage of the flaws.
This discussion has been archived. No new comments can be posted.

Linux systemd Affected by Memory Corruption Vulnerabilities, No Patches Yet More

Linux systemd Affected by Memory Corruption Vulnerabilities, No Patches Yet

Comments Filter:

  • Thats what you get for running systemd (Score:5, Insightful)

    by Shaitan ( 22585 ) on Thursday January 10, 2019 @02:02PM (#57938594)

    Giant bloated executable where trim purpose built utilities and text should be used.

    • Re:Thats what you get for running systemd (Score:5, Insightful)

      by Anonymous Coward on Thursday January 10, 2019 @02:06PM (#57938628)
      Sums up the mantra of UNIX design. Too bad they didn't follow it.

    • Re: (Score:3, Funny)

      by Merk42 ( 1906718 )
      Good thing systemd alternatives haven't had any bugs ever!

      • Re: (Score:3)

        by Shaitan ( 22585 )

        Of course many bugs have been found and fixed in them over the decades.

      • Re:Thats what you get for running systemd (Score:5, Insightful)

        by pereric ( 528017 ) on Thursday January 10, 2019 @02:42PM (#57938916) Homepage

        Of course there have been bugs. But software with a much smaller and well-defined scope (like only being an init system) tend to have less bugs. Also, software with better design choices and better QA tend to have less bugs.

        Also, the dependencies on systemd instead of some independent standard with well-defined interfaces is unfortunate.

        • Comment removed based on user account deletion

          • Re: (Score:3)

            by Etcetera ( 14711 )

            Knowing the quality of 90% of the init scripts I've had to review, I'd be very surprised if there's any overall security advantage to init+the daemons systemd replaced compared with systemd itself.

            You're conflating three different things: service management, init scripts, and the daemons themselves.

            Daemon code quality is out of scope. A bug in the program should be fixed or handled upstream (unless you're a 2019 dev where no one fixes anything because they don't care if it crashes as long as someone spins up another one).

            Init script quality varies *heavily* by distro/ecosystem. Debian/Ubuntu scripts, in my experience, are hot messes. Scripts written to be completely distro agnostic are usually pretty

          • Re: (Score:2)

            by sjames ( 1099 )

            The init scripts are largely irrelevant since they do their job and then go away.

            As for the daemons, they are their own scope under a sane init system.

      • Re: (Score:2)

        by sjames ( 1099 )

        Isn't that a bit like a serial killer trying to excuse himself by claiming all of his victims were jaywalkers?

    • "Giant bloated executable..."

      SystemD causes a lot of problems. That makes more money for people who work for companies that do Linux technology support.

      Is that a giant conflict of interest? Was SystemD allowed by management of Red Hat because it would make more money?

      Mark Shuttleworth said, "Losing graciously" [markshuttleworth.com]. (Feb. 14, 2014} "It will no doubt take time to achieve the stability and coverage that we enjoy today..."

      • Re: Systemd: Conflict of interest? (Score:4, Insightful)

        by Anonymous Coward on Thursday January 10, 2019 @04:06PM (#57939526)

        the one thing I learned at the place I work is that people and businesses are not rewarded for perfect code -- trouble-free code results in the project being thought of as small and not valuable -- if you want money, you need to build complex and buggy code - systemd supporters are no dummies and know what it takes to earn more money

      • Its systemd, not SystemD.

        Have you ever looked at some bash startup scripts? Its difficult to analyse compared to the declarative style. Bash scripts are a much more serious support issue compared to the simplicity of systemd declarative unit files. I've not had any problem with systemd, and not that is worse than what we had with sysv init.

        Also, ubuntu had systemd -like init with Upstart for many years, systemd just standardized so we dont have to learn another init system for every other distro.

        I really

        • "Alexa, start Apache". Smple input to complex code (Score:5, Insightful)

          by raymorris ( 2726007 ) on Thursday January 10, 2019 @04:37PM (#57939828) Journal

          Even simpler than a systemd declaration is saying "Alexa, start Apache".

          That doesn't mean that Alexa's AI code is simpler than a 20-line bash script. You're comparing the *input* to the systemd code, a config file, vs the actual code that does things in SysVinit.

          In sys V, the shell script starts the daemon, it *is* the code. If anything is wrong or you want to change anything, you can look through the shell script and change things. In systemd, the declaration is handed to a binary that does who-knows-what.

          • I don't mind that services have a simple config declaration, with mostly standard start / stop handling. But it would be better to start with some form of "#!/..." so the config file can be used as a script that launches a generic service handler from a traditional init system.

            But that's not the only part of the OS that systemd is trying to replace...

        • Re:Systemd: Conflict of interest? (Score:4, Informative)

          by Etcetera ( 14711 ) on Thursday January 10, 2019 @06:04PM (#57940506) Homepage

          Have you ever looked at some bash startup scripts? Its difficult to analyse compared to the declarative style. Bash scripts are a much more serious support issue compared to the simplicity of systemd declarative unit files.

          Shell, and scripting generally in shell languages, is a key component of all *nix systems. Yes, it's possible to write horrible shell code in an init script, but that's largely the fault of the *author*. Most init scripts are simple; except for whatever custom logic is needed uniquely for this daemon, the rest is boilerplate.

          I'd submit that if you can't understand this code, you're not ready to operate or administer a *nix system at the command line or service management debugging level.
          https://fedoraproject.org/wiki/EPEL:SysVInitScripts#Initscript_template [fedoraproject.org]

          • I've had precisely one problem with an init script, ever. It was that long ago I found the solution in an actual paper book.

            Every systemd based distro I've even tried has given me problems of some kind.

    • These bugs were mainly the result of improperly validating/sanitizing input. Once again [xkcd.com]. The developers weren't thinking about hostile input when they were writing code, and didn't test corner cases. It worked for them!

    • Re: (Score:2, Interesting)

      by Eravnrekaree ( 467752 )

      This is false, systemd is decentralized into 40 independent executables.

      The basic concept of systemd makes sense, you start a list of services first and once that is complete you move onto a seperate list of services . You have unit filed which indicate after target they are a part and which one they depend on. The unit files are simple and easy to understand. An implementation quality issue is a seperate issue from the basic design pattern, the design pattern is a sound concept

      You can still use SysV type i

  • Pure Poettering inspired incompetence (Score:5, Insightful)

    by nyet ( 19118 ) on Thursday January 10, 2019 @02:04PM (#57938606) Homepage

    Looking at the code, all three of these bugs are inexcusable. The systemd devs really are incompetent.

  • Details here: (Score:5, Informative)

    by BringsApples ( 3418089 ) on Thursday January 10, 2019 @02:22PM (#57938764)
    In case you're interested to know the breakdown... [qualys.com]
    • Near the end of the document is this bit:

      Acknowledgments
      We thank systemd's developers, Red Hat Product Security, and the members of linux-distros@openwall.

      That is the more polite version of "you incompetent chumps make our searches easy and worthwhile. And we listened to a lot of System of a Dawn."

  • This is non-news (Score:5, Interesting)

    by gosand ( 234100 ) on Thursday January 10, 2019 @02:23PM (#57938772)

    for me... I switched to Devuan a few months ago.

    Yes, I know there are plenty of bugs and vulnerabilities to go around, but based on the frustrations that systemd caused me, I think I am afforded a bit of schadenfreude.

    • Devuan for sure! Interestingly, MX Linux (steadily climbing up DistroWatch's page hit rankings to #2 at present) allows installation without systemd, but I don't know whether MX has gone to the extent of Devuan in actually ripping it out or just working around it.

  • Shock! Surprise! Dismay! WTF did you expect? (Score:5, Interesting)

    by Seven Spirals ( 4924941 ) on Thursday January 10, 2019 @02:27PM (#57938802)
    Shitty windows-ini-style Unit files, binary logs, 12 different subsystems gobbled up and "integrated" ... I mean did this kind of shit surprise someone? Really? After years of supporting Systemd and solving it's problems for others I can say with limited authority that, yes, it really is garbage. I know there were a few people who thought systemd was just "progress", but no it's a schism, a coup, a shitty revolution that left everyone worse than when they started. Linus and friends are too old and retarded now apparently to lose face and be critical of it because they stood by and shrugged while the Potterites and Fedora assholes ruined Linux. I mean BSD was always better, don't get me wrong. So, it's not as big a loss as some would frame it to be. However, it used to be fun, useful, and relatively untainted by anything this heinous but a few unenlightened windows folks came along and created this svchost.exe ripoff (systemd) for the purposes of enhancing GNOME and now you get this smelly mess that is now Linux. Ah well, it was (sorta) fun while it lasted. Back to my BSD boxes.

    • One of the things that does not make sense about your position is you can use sysv init with systemd, also systemd can generate your text based log files for you. Considering these two facts, systemd can work like how you want it to work. You seem to be more opposed to *other people* using it in ways you do not think they should be allowed to use it. So who is the tyrant?

      • There is a big difference between "can" and "comes that way by default on the OS you use or support". As you may know, the default is to NOT use sysv scripts and NOT log to text files beyond a few simple/useless exceptions (journald steals & encodes it all into a binary opaque format). You are correct that I don't like other people running it. However, you fail to recognize the reason: I support Linux (and a half dozen other Unix variants) professionally, daily, and at a high level. When sysadmins, team

  • Fortunately, I run Linux, not Poetterix and are nicely unaffected.

  • As stated in 2016 at FSCONS in the Q&A https://youtu.be/wMvyOGawNwo?t... [youtu.be]

  • C programming language strikes again (Score:3)

    by Pinky's Brain ( 1158667 ) on Thursday January 10, 2019 @02:42PM (#57938914)

    Two of the bugs only possible in with unsafe referencing/allocation ... par for the course.

    • A basic static code analyzer would have found these. It has nothing to do with C.

      • A basic static code analyser spits out so many false positives on a codebase this size you'd have rewritten half of it by the time you convinced yourself they were all meaningless (and missed the few important ones in the sea of noise).

        • That is why you iteratively tune the analyzer. If you aren't using a static code analyzer you aren't even trying.
      • Comment removed based on user account deletion

    • Re: (Score:2)

      by AHuxley ( 892839 )
      We need an Ada OS.

  • Once again: Slackware NOT affected. (Score:3)

    by sombragris ( 246383 ) on Thursday January 10, 2019 @03:10PM (#57939136) Homepage

    Slackware ships with a simple, effective BSD-style init populated by simple and readable shell scripts. Its BDFL, Patrick Volkerding, made the decision to purposely avoid systemd like the plague and I think he is right.

    Install Slackware, and many sysadmin's worries will go away.

    • Re:Once again: Slackware NOT affected. (Score:5, Informative)

      by Rockoon ( 1252108 ) on Thursday January 10, 2019 @03:29PM (#57939252)

      Slackware ships with a simple, effective BSD-style init populated by simple and readable shell scripts. [....] Install Slackware, and many sysadmin's worries will go away.

      You are missing the forest for the trees. What you really want isnt a "BSD-style init", what you really want is BSD.

      Linux isnt unix, so dont expect it to maintain the unix philosophy. BSD is unix.

      Fun fact: Been true forever

      • Linux isnt unix, so dont expect it to maintain the unix philosophy. BSD is unix.

        As the old saying goes:

        BSD is what you get when a bunch of UNIX hackers sit down to try to port a UNIX system to the PC. Linux is what you get when a bunch of PC hackers sit down and try to write a UNIX system for the PC.

        So that said, I'll stick to my Slackware installs thank you..

      • As someone said, I think there's quite a baby with the bathwater you propose to throw.

      • Slackware - being the oldest distro out there still alive - is as close as standard UNIX as you can come in Linux world.

    • Re: (Score:2)

      by shoor ( 33382 )

      Slack was my 1st linux distro, and I'm a long time admirer of it. But nowadays I use devuan, a systemd free fork of debian. There's also PClinuxOS that is systemd free. For me, the acid test is whether I can use me-tv to watch and record ATSC broadcast TV. Back in the pre-systemd days I could not get me-tv to work on ubuntu but I could get it to work on mint (something to do with the gui libraries). I really liked PCLinuxOS but, last time I tried, I couldn't get me-tv to work on it either, same proble

  • Hang on (Score:3)

    by doom ( 14564 ) <doom@kzsu.stanford.edu> on Thursday January 10, 2019 @03:33PM (#57939276) Homepage Journal
    Let me go make some popcorn.
  • This is a legitimate question. Most people on slashdot seem to hate systemd. And most of you are programmers and work on Linux every day. Why don't you guys get together and create a new init system that blows systemd away? Isn't that what the whole spirit of FOSS is about?

  • Can this be the straw (Score:3)

    by sremick ( 91371 ) on Thursday January 10, 2019 @05:06PM (#57940094)

    ...that broke the camel's back? FINALLY? PLEASE?????

    Can the idiotic pro-systemd folks finally admit they were wrong, abandon the whole misguided concept, and start the process of moving back to unix philosophies and architecture? The world dropped xfree86 fast as a hat, pretty much spun on a dime and moved to X.org.... let that happen w/ systemd as well.

    Or, better yet, just shift support en masse behind FreeBSD and get the hardware and desktop environment and app support back up there like it used to be. Honestly, that'd be the better path and the end result so much better.

    Probably too much to hope for...

  • the unix philosophy (Score:3, Interesting)

    by doom ( 14564 ) <doom@kzsu.stanford.edu> on Thursday January 10, 2019 @05:15PM (#57940150) Homepage Journal

    I come not to praise systemd, and certainly not to praise Poettering or RedHat...

    But these anti-systemd rants would be more impressive if you guys had showed any signs of thinking through what you're saying about The Unix Way and all that jazz.

    Yes, sometimes decentralized, small encapsulated components are a win, but sometimes monolithic designs where the pieces can talk to each other easily are a win-- You might notice that when Linus Torvalds was asked about this he made some rather mild comments about how some aspects of linux, like the graphic display environment has always been more monolithic.

    Arguably, the initial reason perl was a big deal is it took a bunch of features from the shell programming world and stuck them all inside of one process-- you can do lash-ups of shell, awk, sed and so on, or you can just write a perl script and pretty frequently the perl script is really and truly a better option.

    And take a look at some of the classic shell utilities some time. Look at the docs for things like "find", "tar", etc... do they really look to you like something that's designed to just do "one thing"?

    You guys who keep intoning "the unix philosophy" over-and-over might want to stop and think about the way things really get done with unix.

    But then, none of this is a defense of systemd, or the way systemd was put over...

    • Re: (Score:3, Insightful)

      by Anonymous Coward

      Perl is a language. It doesn't do anything on it's own. Executing on the language is the "do one" thing and a completely open interface.

      find, well, finds things. I don't think finding /only/ "one" kind of thing and doing that "well" would make any sense. The "find" is the thing it does. That makes sense. Are you suggesting 'find' means something different?

      tar as we know is Tape ARchive. It's a backup tool. Wait, what you don't want to use it to backup things? ... what would make it not go saving off things?

  • Reflect back on "programs that do one thing and do it well".
    Are the deep parts of an OS you are using still supportive of that philosophy?
    If not consider changing to a better quality OS.

Slashdot Top Deals

He has not acquired a fortune; the fortune has acquired him. -- Bion

Close