back to article Don't panic, but Linux's Systemd can be pwned via an evil DNS query

Systemd, the Linux world's favorite init monolith, can be potentially crashed or hijacked by malicious DNS servers. Patches are available to address the security flaw, and should be installed ASAP if you're affected. Looking up a hostname from a vulnerable Systemd-powered PC, handheld, gizmo or server can be enough to trigger …

Page:

  1. Chairo

    Ohh, so surprised, how could this happen?!?

    </irony>

    Anyway. Given how this octopus spreads its arm in so many modules, this is probably only the very tiny tip of a very big and cold iceberg.

    1. Doctor Syntax Silver badge

      "Given how this octopus spreads its arm in so many modules, this is probably only the very tiny tip of a very big and cold iceberg."

      Regret I can't give you a second upvote for a glorious mixed metaphor.

    2. Anonymous Coward
      Anonymous Coward

      Well I am affected

      "Patches are available to address the security flaw, and should be installed ASAP if you're affected."

      But what do my mannerisms have to do with it?

      1. EastFinchleyite

        Re: Well I am affected

        Given that it is Systemd that is the problem I think the appropriate response would be a gallic shrug.

        https://www.youtube.com/watch?v=ubdrDij0x48

        1. Ramazan

          Re: I think the appropriate response would be a gallic shrug

          Let me provide an analogy. You know, xpdf frequently had code execution vulnerabilities found in it and ultimately was removed from Gentoo in 2014 when another one resurfaced and became the last straw:

          https://security.gentoo.org/glsa/201402-17

          "Description: Multiple vulnerabilities have been discovered in Xpdf. Please review the CVE identifiers referenced below for details.

          Resolution: Gentoo has discontinued support for Xpdf. We recommend that users unmerge Xpdf: # emerge --unmerge "app-text/xpdf"

          After that, there's no more xpdf in Gentoo. They use mupfd instead. I hope systemd meets the same fate, the sooner the better. Flushing toilet water icon, please.

      2. M man
        Coat

        Re: Well I am affected

        you Forgot your'e pedents' coat .

      3. Anonymous Coward
        Anonymous Coward

        Re: Well I am affected

        "But what do my mannerisms have to do with it?"

        Yeah!

        *Downs a pint and belches*

        *Takes off shirt before putting a shelf up*

        *Minces off to find a drill*

    3. Updraft102 Silver badge

      Very warm icebergs are just called water.

    4. John Sanders
      Linux

      I use systemd on all the servers I manage, out of choice. I refuse to set up non-systemd server-setups any more, it is just so vastly more pleasant to work with than the alternatives.

      So, for me personally, when systemd came along, it solved all the problems I ever had with system initialization. What most systemd critics consider "bloat", I consider necessary complexity to solve a complex problem generically. You can say what you want about Poettering, but he actually realized what the problems with system initialization were and provided a working solution. I could go on for hours, but this should be a good summary.

      A lot of the pushback against systemd - merited or not - is because a lot of people in charge of little parts of the bazaar have seen their pet projects cast aside by the major distros and taken over by the systemd devs. In a world where street cred is a big force in motivating people to contribute to open source being maintainer of 'x' where 'x' is part of each and every linux distro out there and then to see 'x' taken over by systemd in a fairly rough manner without any kind of co-operation between the old maintainers and the new kids on the block there are bound to be a lot of ruffled feathers. But that's not technology, that's just ego.

      I find amusing that no one here is asking why systemd-resolved was introduced, or what problem was it intended to solve, read this post:

      https://lists.ubuntu.com/archives/ubuntu-devel/2016-May/039350.html

      1. Anonymous Coward
        Anonymous Coward

        systemd might as well have been written by Microsoft

        Everything that is wrong with systemd is down to it M$ style design, it doesn't belong on professional systems anymore than windows does.

        Yes, you gain ease of use and fast setup but at the cost of security and stability with the obvious result that you open yourself up to security problems that occur because you let someone else make the decisions you thought weren't as important as getting up and running.

      2. Graham Dawson

        The pushback against systemd is because it takes what were independent systems and rolls them into a tightly coupled monolith. The independence of those prior systems was their greatest strength - the more independent those systems are, the less opportunity there is to bring down the entire OS by crashing one of those systems.

        systemd can claim to be modular all it wants; the fact that you can take down the entire OS via the init with a malicious dns response is a fucking travesty in this day and age. It's the sort of thing that even Windows left behind at the turn of the century.

        1. Martyn Welch

          I don't follow...

          Can you explain to me your rationale for believing that "you can take down the entire OS via the init with a malicious dns response" when systemd-resolved is quite clearly a separate binary from that running as init and has also dropped its privileges and is running as a non-root user?:

          # ps | grep init

          1 root 7824 S {systemd} /sbin/init ldb

          1108 root 2696 S grep init

          # readlink -f /sbin/init

          /usr/lib/systemd/systemd

          # readlink -f /usr/lib/systemd/systemd-resolved

          /usr/lib/systemd/systemd-resolved

          # ps | grep systemd-resolved

          359 systemd- 5816 S /usr/lib/systemd/systemd-resolved

          1097 root 2696 S grep systemd-resolved

          # cat /etc/passwd | grep systemd-resolve

          systemd-resolve:x:231:231:systemd-resolve:/:/bin/nologin

          systemd-resolve:x:231:

          # cat /etc/group | grep systemd-resolve

          systemd-resolve:x:231:

          #

      3. Tom 38 Silver badge

        I find amusing that no one here is asking why systemd-resolved was introduced, or what problem was it intended to solve, read this post:

        To paraphrase for anyone not wanting to read it: "DNS is probably too complex for you to manage, so we're adding an extra caching resolver to every machine, which simplifies certain desktop configurations".

        If I'm going to be treated like a child, I expect milk and cookies at 3pm, and then a nap.

      4. Ramazan

        Re: I refuse to set up non-systemd server

        Let me fix it for ya, John:

        "I use xpdf on all the computers I manage, out of choice. I refuse to set up non-xpdf setups any more, it is just so vastly more pleasant to work with than the alternatives."

        (https://security.gentoo.org/glsa/201402-17)

      5. Anonymous Coward
        Anonymous Coward

        > I use systemd on all the servers I manage, out of choice.

        Yeah, there is always one.

    5. This post has been deleted by its author

  2. -tim
    FAIL

    Trust a hackers data?

    I've always found it odd that systems would enable dns reverse lookups for all sorts of things where it provides no value. I don't trust DNS to give me a valid name if all I have is an IP address.

    The whole thing of probing someone's network and have them look up your IP address where you then send TCP packets back to crash their name server or other application has been around since the early 1990s.

    1. Orv Silver badge

      Re: Trust a hackers data?

      It also adds an unpredictably slow, often blocking process to whatever you're doing. There are situations where it's useful, but almost all of them are better handled in after-the-fact processing by non-privileged code.

      However, there are other scenarios where this bug could trigger. For example, if you're using an untrusted network that can intercept your DNS queries.

    2. Jamie Jones Silver badge

      Re: Trust a hackers data?

      I've always found it odd that systems would enable dns reverse lookups for all sorts of things where it provides no value. I don't trust DNS to give me a valid name if all I have is an IP address.

      That's why you also look up the name to see it matches the same IP address, otherwise there's no point, in fact it's worse than no lookup at all if the name is logged instead of the IP.

      DNS Double Reverse Lookup

      The whole thing of probing someone's network and have them look up your IP address where you then send TCP packets back to crash their name server or other application has been around since the early 1990s.

      That's a daft thing to say. If someones name server can be crashed this way, then it is at fault, and needs to be fixed. Nothing to do with DNS lookups, apart from maybe reducing "security by obscurity", which of course is a non-reason.

      1. -tim

        Re: Trust a hackers data?

        To people who think reverse DNS is a good idea, consider concepts like CNANE loops. Smart DNS servers will catch it but there are plenty of dumb DNS implementations out there. In IPv4 we could send a UDP request out and expect to get a UDP response back but now with IPv6, the packet sizes often exceed the MTU resulting in several packets. Once you get a large chunk of data back, someone at the other end might just be playing games with malformed DNS packets or even just broken DNS settings. What does you application do when you get back thousands names for a reverse lookup? What happens when each lookup results in a chain of CNAMES? What happens when the end of those chains result in hundreds of addresses that are all the same?

        DNS isn't authoritative, it is informational. It is great when it doesn't lie to you. But you can't test for when it does.

  3. bombastic bob Silver badge
    Mushroom

    If THIS isn't a reason to hate systemd...

    IF! THIS! IS! NOT! A! REASON! TO! HATE! SYSTEMD! THEN! THERE! IS! NO! HOPE! FOR! YOU!!!

    just sayin'.

    1. Solarflare

      Re: If THIS isn't a reason to hate systemd...

      Is systemd made by Yahoo! or something? What's with all the exclaimation marks?

      1. John Smith 19 Gold badge
        Coat

        "What's with all the exclaimation marks?"

        They don't call him "Mr Bombastic" for nothing.

        1. bombastic bob Silver badge
          Devil

          Re: "What's with all the exclaimation marks?"

          https://allthetropes.org/wiki/Punctuated!_For!_Emphasis!

          (El Reg does it all the time, too)

          1. jake Silver badge

            Re: "What's with all the exclaimation marks?"

            But only for Yahoo!, bb.

            If you must use emphasis, please don't feel free. But not seemingly at random, or you come off all WWW-newbie "ransom note school of design".

      2. Naselus

        Re: If THIS isn't a reason to hate systemd...

        Shhh, just be happy he didn't try and blame this one on Hillary Clinton.

      3. Chemical Bob

        Re: If THIS isn't a reason to hate systemd...

        "What's with all the exclaimation marks?"

        A Yahoo commented(?)

    2. sabroni Silver badge

      Re: If THIS isn't a reason to hate systemd...

      Getting rid of systemd won't stop buffer overruns. This vulnerability is handy for the systemd haters but the real problem here is coding in a language that allows overruns to happen, isn't it?

      1. Dan 55 Silver badge

        Re: If THIS isn't a reason to hate systemd...

        No, the real problem is systemd is a jack of all trades and a master of none. Thus, bugs like this due to poor quality design and coding.

        1. rtfazeberdee

          Re: If THIS isn't a reason to hate systemd...

          ALL software has bugs, get over it. Looks like you've never written any software in your life

          1. Dazed and Confused Silver badge

            Re: If THIS isn't a reason to hate systemd...

            ALL software has bugs, get over it.

            It is precisely because all software has bugs that design decisions should be made to limit the impact of those bugs. It's like RAID, all disks are unreliable, eventually the industry twigged that the answer wasn't to make more reliable disks (even though that helped a bit) the answer was to design storage systems where disks dying wasn't a big problem.

            When it comes to SW the trick is to make sure that you're not exposed to the risk of bugs unnecessarily. Design your SW so as to limit the impact of the inevitable bugs.

            1. Tom 38 Silver badge

              Re: If THIS isn't a reason to hate systemd...

              When it comes to SW the trick is to make sure that you're not exposed to the risk of bugs unnecessarily. Design your SW so as to limit the impact of the inevitable bugs.

              It's unclear whether you think that the language should have protected the developer from risks, or that the software should have been composed of more coherent, smaller, and less tightly coupled components.

              1. stephanh Silver badge

                Re: If THIS isn't a reason to hate systemd...

                @ Tom 38

                > It's unclear whether you think that the language should have protected the developer from risks, or that the software should have been composed of more coherent, smaller, and less tightly coupled components.

                I think both. A traditional "init" is written in C but most of the functionality is actually in shell scripts which are invoked by "init". Now shell is messy, but at least it is not vulnerable to buffer overruns. In principle there is nothing stopping you from rewriting the shell scripts in some saner programming language (Python, Ruby, whatever rocks your boat).

                Note that dividing the software in smaller blocks also means that you can use an appropriate programming language for each block.

          2. Dan 55 Silver badge

            Re: If THIS isn't a reason to hate systemd...

            And that's an argument in favour of a giant monolithic buggy piece of software?

            Many things that systemd does are bad copies of stand-alone software with reduced functionality and/or bugs. If it were a stand-alone DNS daemon then you could easily change to another one.

            Why would you even want to shove everything in the same process? If it goes down the system is hosed, if it's exploited then all functionality that systemd does is compromised.

            1. John Sanders
              Meh

              Re: If THIS isn't a reason to hate systemd...

              >> If it were a stand-alone DNS daemon then you could easily change to another one.

              Dude, you can just do that, systemd-resolved is a separate module.

              systemd stop systemd-resolved

              systemd disable systemd-resolved

              systemd mask systemd-resolved

              apt update

              apt install dnsmasq

              I guess this is the 21st century version of the peasants with pitchforks.

              1. Anonymous Coward
                Anonymous Coward

                Missing the point

                I cringe every time I hear someone try to deflect the storm of _VALID_ criticism that blows in when someone brings up systemd by dismissing the fact that the problem can be fixed/worked around/removed and or put back to the way it was when it was still working.

                Yeah, it's replaceable, but you'd have to replace it EVERY TIME, SYSTEM by SYSTEM. You'd have to regression test ever major version upgrade to make sure it doesn't turn itself back on. You may not even have root access on the underlying system. Ever hear of cloud hosting?

                There are real problems with systemd. It breaks things. If we have to fix something that wasn't broken before, THAT IS A PROBLEM. A problem that we didn't have before and we now have to fix.

          3. stephanh Silver badge

            Re: If THIS isn't a reason to hate systemd...

            @ rtfazeberdee

            All software has bugs, therefore software like init, which runs as the very first process and with elevated permissions, should be kept as simple as possible.

            In contrast, the systemd developers have included a ridiculous amount of functionality into the init process. (process 1). See http://suckless.org/sucks/systemd for an overview. Often for no other stated reason than to "keep the number of processes down".

            A traditional init system wouldn't even contain networking code, let alone do reverse DNS lookups.

            Consider that it is generally estimated that high-quality code contains one defect every 1000 lines. Consider the size of systemd, all of which is running as the privileged process 1. Weep.

            1. This post has been deleted by a moderator

              1. Stevie Silver badge

                Re: All software has bugs

                Well, if people would start from the principle espoused by Bertrand Meyer in Object Oriented Software Construction vis-a-vis undefined answers to questions (a principle that goes back much further than the publication of that book I might add) there would be a damned sight fewer stupid ones.

              2. boltar Silver badge

                Re: If THIS isn't a reason to hate systemd...

                "its the most ignorant thing said about systemd, go and learn something before you open your mouth and spout nonsense."

                God, you truly are an utter fool. I seriously hope you're not involved in software development in any way.

          4. Anonymous Coward
            Anonymous Coward

            @ rtfazeberdee "ALL software has bugs"

            "bad software has bugs" FTFY

            Every person who has done any coding will have made a "hello world", the ones who progressed will have made certain that it worked before moving on, so clearly it is possible for all competent coders to write without bugs. Mathematically that is a lot of good code that proves that not all software has bugs

            The excuse that the complexity of coding is greater than any other human endevour is also clearly false as computers are fundementally simple in operation. The computers never get confused only programmers.

            The "all software has bugs" and "computers are so complex we should be excused for our mistakes" are Urban myths i.e both false but have been repeated so often that people actually believe them true. M$ I am looking at you

            IMHO anyone who quotes either of them is either a shill and/or an incompetent.

            1. Kiwi Silver badge
              Boffin

              Re: @ rtfazeberdee "ALL software has bugs"

              The "all software has bugs" and "computers are so complex we should be excused for our mistakes" are Urban myths i.e both false but have been repeated so often that people actually believe them true. M$ I am looking at you

              If you type with 99% accuracy that means on average you mis-type one character in every 100. With red squiggly underlines and the like you can pick up typos where the typed word is not found in the dictionary, but if you type "cant" where you meant "can't", there's a good chance you'll not pick up the typo.

              Where that typo is a number in a program of a few million lines of code, each done by several people over the years, you will only find it if the typo causes a compile error or warning, or if it eventually causes a noticeable failure in the software. In some cases (eg Heartbleed or EternalBlue) those bugs can take a number of years to be noticed, because the flaw is not triggered in such a way as to cause a problem.

              But there's other bugs as well, such as a condition the programmer never thinks to test for (no, you cannot test beyond your experience and beyond what is suggested to you), your code might work flawlessly on every possible situation, but someone has a single pixel in a photo that is #FFEE66 and something in your code reacts with that, and you tried a few hundred thousand colours in your testing but just not that one. It could be a slight delay in how one CPU processes commands, or a system configuration that fragments memory in some weird way, or... So many things you cannot possibly expect and test for.

              When code gets beyond a few 10s of lines it becomes hard to spot typos and other bugs. Transpose a couple of digits, not have an obvious flaw at compile and testing, the bug will ship. You may never know it exists, or it may be found the day after shipping. That's why patching systems in professional-grade OS's (and software) work so beautifully, because we need to be able to fix software when someone finds something is wrong.

              Theoretically it is not impossible to write perfect code in a complex program. In theory you could type every character in a couple of million lines without one typo. In reality, most humans struggle even to get to a mere 90% typing accuracy (that's one mistake in every 10 characters typed!).

              1. Anonymous Coward
                Anonymous Coward

                Re: @ kiwi "ALL software has bugs"

                That human's err is not unknown, since we know this then we can take actions to mitigate the chances of a typo being an issue.

                It reminds of electronic projects from my youth and machine code programming onto an EPROM via entering the hex and manually writing it byte by byte, if you made one fat fingered mistake then you had to wipe it and start again. Whilst it was an absolute pain it was possible, with sufficent diligence and practice input errors disappeared.

                Flash forwards a few decades and people are saying that it is not possible to avoid typos in a highlevel programming language which has lots of verification tools to help, from my experience if you cannot manage to avoid typos ending up in your finished code then clearly things have been made too easy for you to enter bad data. Perhaps if compilation error detection wiped your source you might learn to code without errors too.

                The lessions I learned were to be certain of what your are entering and keep things small so you do not have to maintain that level of concentration for too long. Now programming is so much easier we seem to have lost the discipline and especially the attention to detail.

                Bug free code is possible but why bother when enough people believe that it is not

                1. Kiwi Silver badge

                  Re: @ kiwi "ALL software has bugs"

                  om my experience if you cannot manage to avoid typos ending up in your finished code then clearly things have been made too easy for you to enter bad data

                  I referred to rates of typing mistakes in my post, and I stand by that. Sure, with experience like yours you can become much better than average at typing accuracy, but is that at the sacrifice of speed?

                  I don't know of any tool for entering bad data other than the keyboard BTW. Well, you could probably use some voice recog or mouse-driven interface but speed drops quite a bit there, keyboard is still the fastest way to enter words into a computer IME (am looking for decent voice stuff but little out there).

                  A compiler will pick up obvious errors, and may pick up a number of other errors that would still compile but there's something "not quite right", but there's a lot of stuff that can be syntactically perfect, make perfect sense to you when you read the code, but still not be doing what it's supposed to.

                  But you can guarantee that every number you've entered into code is right? You've never noticed that you'd accidentally transposed a couple of variables (or a variable and a constant)? Never forgotten to remove debugging stuff ( {ifdef debug..} ) wrapped around what should be a random number but you were using a constant so you could test the code? You're either one in several billion, or maybe your code isn't that complex.

                  BTW, I can spot a half a dozen potential grammar errors and few typos, and at least one word-choice error in your short message! :)

      2. Dazed and Confused Silver badge

        Re: If THIS isn't a reason to hate systemd...

        Getting rid of systemd won't stop buffer overruns.

        No it won't be getting rid of buffer overruns, but something as critical to system operation as systemd simply should never be placed in a position where it can be exposed to this kind of attack, or any kind of remote attack. That's not an "I hate systemd" statement, that's a basic security for kindergarten level lesson.

        Fixing these issues is going to be a giant game of wack'o'mole where there is simply no need to expose yourself to danger in the first place. This isn't just a bug it's a fundamental design flaw.

        1. Tinslave_the_Barelegged Silver badge

          Re: If THIS isn't a reason to hate systemd...

          > Fixing these issues is going to be a giant game

          This is progress, mind you, as it's surprising the official response wasn't the usual "WONTFIX - upstream DNS is to blame"

      3. Missing Semicolon Silver badge
        Flame

        Re: If THIS isn't a reason to hate systemd...

        No, the reason to hate systemd is that Linux already has a bunch of DNS resolvers that are pretty secure. You can pick your favourite.

        But systemd must use its own, special, freshly-written one. Because, systemd. So that decision obliges most Linux distros to host a single, new DNS resolver. That is broken.

        Unfortunately, this has been the way with systemd for a while. New way of doing things becomes The One, True, Only Way before the code is actually fully finished and tested. And, if bugs are found, or pre-existing features are removed, it is your fault for trying to do whatever you used to do before.

        So, yeah, hate. Just been embarrassed in front of a customer by the COMPLETELY UNNECESSARY change to the way that partitions (especially swap) are mounted. Oh, and did you know, that if your machine ceases to boot because of a systemd config error, you can't fix it in the recovery console?

        Bah!

        1. Doctor Syntax Silver badge

          Re: If THIS isn't a reason to hate systemd...

          @ Missing Semicolon

          Whilst I agree with the sentiment the article makes it clear that use of the systemd resolver isn't compulsory. Yet. At least not if you use Debian.

          1. bombastic bob Silver badge
            Devil

            Re: If THIS isn't a reason to hate systemd...

            "the article makes it clear that use of the systemd resolver isn't compulsory. Yet. At least not if you use Debian."

            this is true. my Debian 8 'beater' box [which I'm using to test changes/updates to a customer web site before implementing them on the actual site] has systemd on it, unfortunately, but isn't using resolved for anything significant (or at all, for that matter).

            /etc/resolv.conf is a regular file with the expected text-based contents in it

            I think you may be able to DISABLE systemd-resolved by making /etc/resolv.conf a static file, rather than a symlink to the /run/systemd/whatever file. Can anyone confirm that?

        2. This post has been deleted by its author

Page:

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2019