Stories
Slash Boxes
Comments

SoylentNews is people

posted by n1 on Thursday November 13 2014, @03:19AM   Printer-friendly
from the one-daemon-to-rule-them-all dept.

Whether you're running systemd happily or begrudgingly, it's best if you disable systemd-resolved as your DNS resolver for the time being. Reported today at seclists is a new DNS cache poisoning bug in systemd-resolved.

At its simplest, an attacker triggers a query to a domain he controls via SMTP or SSH-login. Upon receipt of the question, he can just add any answer he wants to have cached to the legit answer he provides for the query, e.g. providing two answer RR's: One for the question asked and one for a question that has never been asked - even if the DNS server is not authoritative for this domain.

Systemd-resolved accepts both answers and caches them. There are no reports as to the affected versions or how widespread the problem may be. Comments over at Hacker News suggests that it might not be widespread, most users would still be running the backported 208-stable while the DNS resolver was committed in 213 and considered fairly complete in 216, but that is if they enabled systemd-resolved in /etc/nsswitch.config.

 
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: 1) by Whoever on Thursday November 13 2014, @06:03AM

    by Whoever (4524) on Thursday November 13 2014, @06:03AM (#115436) Journal

    I recently enabled it on my htpc because inetctl was taking a solid 3 seconds to bind a static IP on boot compared to 90ms for systemd to do it.

    You are assuming that inetctl is doing the same as systemd. For example, maybe when inetctl brings up an interface, it does an arping to check that the IP address is not already in use?

  • (Score: 0) by Anonymous Coward on Thursday November 13 2014, @06:25AM

    by Anonymous Coward on Thursday November 13 2014, @06:25AM (#115442)

    I know it does arp checks, but even when I wrote a static config for my nic and disabled all of the extra shit it was still taking 50x longer than dhcpcd or systemd-networkd w/ systemd-resolved, which is absolutely disgusting.

    none the less, my point was that systemd-resolved isn't enabled by default.

    • (Score: 0) by Anonymous Coward on Thursday November 13 2014, @07:47AM

      by Anonymous Coward on Thursday November 13 2014, @07:47AM (#115464)

      Why not just use ifconfig

      • (Score: 0) by Anonymous Coward on Thursday November 13 2014, @09:30AM

        by Anonymous Coward on Thursday November 13 2014, @09:30AM (#115488)

        ifconfig has been deprecated for years...

        • (Score: 4, Informative) by canopic jug on Thursday November 13 2014, @09:48AM

          by canopic jug (3949) Subscriber Badge on Thursday November 13 2014, @09:48AM (#115492) Journal

          ifconfig may have been deprecated but the intended replacement ip [die.net], if it is an intended replacement, is so complicated as to be almost broken. At least ifconfig was something you could show beginners and even intermediate users did not need to pore over the manual to resolve basic tasks. I'm a fan of tools with a clear purpose and clean design that don't need much documentation. As such it is more convenient to me when the tools ifconfig and route remain separate rather than mashed into an unwieldy conglomerate like ip. That is one of the many problems with systemd, but specifically it is one that is shared with a surprising number of other tools. I wonder where the stupidity is coming from or if it is just classic second-generation software mistakes. The second generation of most projects tend to be very much overly engineered.

          --
          Money is not free speech. Elections should not be auctions.
          • (Score: 0) by Anonymous Coward on Thursday November 13 2014, @11:34AM

            by Anonymous Coward on Thursday November 13 2014, @11:34AM (#115505)

            agreed, but even with ifconfig or ip, you still had to write shell scripts just to bring up a network and honestly that's insane. I'm a fan of simplicity and honestly, if I have to jump through hoops to do something so basic like say binding a static IP to a network, the software is a failure. this is inherently a problem among newer developers, they take a simple, working piece of software, base their model around it with the need to "improve" it, only to fuckup so badly that it almost unfathomable as to why anyone would want to use it compared to the original.

            • (Score: 2) by zeigerpuppy on Thursday November 13 2014, @01:11PM

              by zeigerpuppy (1298) on Thursday November 13 2014, @01:11PM (#115521)

              I've never had to write a script to bring up a network.
              Editing a config file, yes (/etc/network/interfaces).
              But the settings need to be stored somewhere so it's about as simple a solution as there could be.
              Especially considering that a DHCP network connection will be auto configured on install.
              Current Linux networking works pretty well and logically but it's not a mind reader, nor is any other os as far as I know.

              • (Score: 1, Insightful) by Anonymous Coward on Thursday November 13 2014, @01:30PM

                by Anonymous Coward on Thursday November 13 2014, @01:30PM (#115531)

                The last time I had to write a script to configure networking on a desktop/workstation Linux system was 1998.

                Systemd is trying to "solve" a problem that hasn't existed for 15 years.

                • (Score: 1, Funny) by Anonymous Coward on Thursday November 13 2014, @02:55PM

                  by Anonymous Coward on Thursday November 13 2014, @02:55PM (#115562)

                  Some people have far more complex network configuration problems than you and use scripts to autoconfigure images that they've deployed to hundreds of virtual and bare metal servers.

                  SystemD solves this by making it impossible to have multipath fiberchannel storage area networks.