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.
(Score: 0) by Anonymous Coward on Thursday November 13 2014, @03:35PM
Posting anon as I've already moderated. This to me is the crux of the whole systemd debate; it's an all-or-nothing approach. No Plan B. Not Invented Here syndrome taken to its logical absurd conclusion.
I think the best terms I saw in describing systemd (in comparison to the linux kernel which was also being described as a "monolithic blob" with the implication that it should be considered just as unpalatable as systemd) was the following:
* The linux kernel is a monolithic design, but a modular contrustion
* systemd is a modular design, but a monolithic construction
Point being that all the various components of systemd are so tightly coupled and interwoven that it's practically impossible to separate one from t'other. If I could, I would have absolutely no problem with it (nor with debian implementing it) - if I could install the parallel startup and event-driven initty bits, great, sure I could find a use for them somewhere. I could install the binary logging component whenever I thought my day didn't have enough brain haemmorhages but uninstall it from all my servers. Use the systemd NTP and DHCP gubbins on the client systems I don't really care about but keep crusty-old-ancient-stone-aged-but-works ntpdate and dhcpd on my servers. And so on and so forth. To me, that's the UNIX philosophy - keep things small and tightly focussed so they can be thrown out at the drop of a hat when something better comes along. I don't understand why, on both a technical and philosophical basis, this couldn't have been written in from the start.
But as it is, the construction doesn't seem to allow any of that, it's an all-or-nothing approach that, from my POV as a server admin, answer use cases that are of no interest to me. Does it make life easier for desktop users? Maybe. But I don't really care. All I see are decades of bug fixes being swept under the rug before the dubious vacuum of Progress comes along.
(Score: 0) by Anonymous Coward on Thursday November 13 2014, @09:08PM
Posting anon as I've already moderated
Currently, you can mod -first- then come back afterwards and post to the thread (signed in) without undoing your moderation.
This does NOT work that way on the other site.
-- gewg_