Stories
Slash Boxes
Comments

SoylentNews is people

Lennart Poettering Wins 2017 Pwnie for Lamest Vendor Response

posted by martyb on Monday July 31 2017, @05:01AM   Printer-friendly
from the imminent-recursion dept.

canopic jug writes:

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!"

Original Submission

 
This discussion has been archived. No new comments can be posted.
Lennart Poettering Wins 2017 Pwnie for Lamest Vendor Response | Log In/Create an Account | Top | 73 comments | Search Discussion
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: 2) by pvanhoof on Monday July 31 2017, @03:16PM (2 children)

    by pvanhoof (4638) on Monday July 31 2017, @03:16PM (#547183) Homepage

    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?

    Starting Score:    1  point
    Karma-Bonus Modifier   +1  
    Total Score:   2  

  • (Score: 3, Insightful) by sjames on Monday July 31 2017, @04:49PM

    by sjames (2882) on Monday July 31 2017, @04:49PM (#547240) Journal

    ...you'd have to do something like init sh=/bin/sh and mount the FS writable yourself and stuff like that).

    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

    by Gaaark (41) on Tuesday August 01 2017, @02:16PM (#547651) Journal

    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 ---