SoylentNews

Systemd-resolved Subject to Cache Poisoning

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

DECbot writes:

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.

• Re:WTF mate? (Score: 4, Interesting) by zocalo on Thursday November 13 2014, @01:33PM

  by zocalo (302) on Thursday November 13 2014, @01:33PM (#115533)

  I quite agree; my point was more about the original post and its incorrect moderation as "Troll" when it should actually be "Informative". Yours is also the main criticism that I have about the way SystemD is being "forced" on end users by the distro maintainers, although I can understand why they are doing it - it's simply the easiest option. One reason for that seems to be that as more and more packages expect SystemD to be present (not specifically the fault of the SystemD developers, although suspecting Red Hat etc. to have a hand in this is fair game, IMHO), untangling those dependencies to use alternatives to SystemD is more work than they are prepared to undertake - if it's possible at all. They could opt for an alternative tool that doesn't require SystemD, but then they'd have users complaining about why their favourite tool isn't included / requires a specific set of build options / just doesn't work, so again the path of least resistance wins out.
  
  Similarly, SystemD's internal interdependancies between its modules are confusing a lot of people about just how modular it is. It's certainly not a monolithic single binary, yet many of the interdependencies between the various daemons are so tight that it might as well be (I can accept that SystemD daemons might require the PID1 component to work, but some of their inter-dependencies are specific to SystemD and don't exist between the daemons they replace). In theory, if SystemD were truly just a bundle of daemons then you would expect to be able to package up many, if not all, of those daemons into their own packages and optionally install either those or an alternative depending on your personal needs and preferences - and any specific application needs. I've not really looked, but I've not heard of a single distro that has even attempted to package SystemD up in a modular manner like this, yet doing so would wipe out a lot of the criticisms people commonly levelled at it. I'm looking particularly hard at Fedora here; SystemD is effectively a Red Hat sponsored project, Fedora is (esssentially) their test bed, and they been busy breaking up other packages into sub-packages in this manner for quite some time now. That SystemD hasn't got that treatment makes me think it might not actually be possible, or the dependencies are such that you are going to need all the modules anyway, neither of which really helps make the case for claims to modularity being much more than word games.

  --
  UNIX? They're not even circumcised! Savages!

  Parent

  Starting Score:	1		point
  Moderation		+2
  Insightful=1, Interesting=1, Total=2
  Extra 'Interesting' Modifier		0
  Karma-Bonus Modifier		+1
  Total Score:		4