SoylentNews is people
SoylentNews
The 2017 Pwnie winner for lamest vendor response goes to Lennart Poettering for systemd. According to CSO which has reported on it, the Pwnie winners which were announced a few days ago, the summary for Lennart and systemd reads as follows:
The most spectacular mishandling of a security vulnerability by a vendor ended up winning a Pwnie for Lennart Poettering due to SystemD bugs 5998, 6225, 6214, 5144, 6237. The nomination reads: "Where you are dereferencing null pointers, or writing out of bounds, or not supporting fully qualified domain names, or giving root privileges to any user whose name begins with a number, there's no chance that the CVE number will referenced in either the change log or the commit message. But CVEs aren't really our currency any more, and only the lamest of vendors gets a Pwnie!"
(Score: 2) by digitalaudiorock on Monday July 31 2017, @03:00PM (3 children)
So it's somehow not an issue when the end user themselves creates a unit file with user 0day and systemd quietly "sanitizes" the "input"...that is, it ignores the user, and quietly runs as root? Apparently LP agrees with you, and that's the problem. This shows that they put NO thought at all into the ramifications of their error handling. That sort of shit isn't even programming 101, it's just common sense for most of us. The only sane options where were to either a) accept the user if it was a valid user, or b) hard fail and refuse to start the service due to an invalid configuration...NOT to quietly use root.
This is just as stupid as the DNS issue where they were stripping underscores from DNS names because they "shouldn't be there". Again...blindly "sanitizing" the input thus guaranteeing that they were attempting to look up an incorrect name. These people are provably clueless. The scary part is that their basic design concepts from the beginning about about 1000 times worse than their clueless execution.
(Score: 2) by pvanhoof on Monday July 31 2017, @03:16PM (2 children)
Relax. You are throwing a lot of stupid here and about about 1000 worse than clueless this and that. With that communicationstyle, you're not helping yourself making your (probably reasonable) argument.
I'm sure the idea was that a init system cannot make worse choices like not booting the system in case of a misconfiguration. Because then the system is broken beyond repair (since init 1 or init single from GRUB might also no longer work, you'd have to do something like init sh=/bin/sh and mount the FS writable yourself and stuff like that).
Maybe they should indeed in the unit files have something like "This is a boot critical service that should, if the user doesn't exist, fall back to root user". I'm not a systemd developer nor a init expert. But I can certainly imagine that just refusing to start the service can be the wrong choice, too. Because them deleting a user can mean that the system no longer boots.
I wonder what inetd and xinetd do in this situation. Do they fall back to root too?
(Score: 3, Insightful) by sjames on Monday July 31 2017, @04:49PM
So not at all beyond repair then.
Running as root when explicitly told not to is just plain wrong and dangerous. The correct answer is don't run that service at all and move on. Next best (a distant second) would be run as nobody and hope for the best.
(Score: 2) by Gaaark on Tuesday August 01 2017, @02:16PM
Not fully up on this (my memory is failing me.... tired beyond belief), but shouldn't it fall back to root LOGIN instead of root logged in?
--- Please remind me if I haven't been civil to you: I'm channeling MDC. ---Gaaark 2.0 ---