Systemd Named 'Lamest Vendor' At Pwnie Security Awards (theregister.co.uk)
Long-time Slashdot reader darkpixel2k shares a highlight from the Black Hat USA security conference. The Register reports:
The annual Pwnie Awards for serious security screw-ups saw hardly anyone collecting their prize at this year's ceremony in Las Vegas... The gongs are divided into categories, and nominations in each section are voted on by the hacker community... The award for best server-side bug went to the NSA's Equation Group, whose Windows SMB exploits were stolen and leaked online this year by the Shadow Brokers...
And finally, the lamest vendor response award went to Systemd supremo Lennart Poettering for his controversial, and perhaps questionable, handling of the following bugs in everyone's favorite init replacement: 5998, 6225, 6214, 5144, and 6237... "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," reads the Pwnie nomination for Systemd, referring to the open-source project's allergy to assigning CVE numbers. "But CVEs aren't really our currency any more, and only the lamest of vendors gets a Pwnie!"
CSO has more coverage -- and presumably there will eventually be an official announcement up at Pwnies.com.
And finally, the lamest vendor response award went to Systemd supremo Lennart Poettering for his controversial, and perhaps questionable, handling of the following bugs in everyone's favorite init replacement: 5998, 6225, 6214, 5144, and 6237... "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," reads the Pwnie nomination for Systemd, referring to the open-source project's allergy to assigning CVE numbers. "But CVEs aren't really our currency any more, and only the lamest of vendors gets a Pwnie!"
CSO has more coverage -- and presumably there will eventually be an official announcement up at Pwnies.com.
Marked NOTLAME, WONTACCEPT, closed.
Also, lameness filter.
You have got to be fucking kidding me: systemd can't handle the process previlege that belongs to user name startswith number, such as 0day #6237
And what's worse is Pottering's complete lack of UNIX awareness.
Yes, as you found out "0day" is not a valid username. I wonder which tool permitted you to create it in the first place. Note that not permitting numeric first characters is done on purpose: to avoid ambiguities between numeric UID and textual user names.
Somehow FreeBSD doesn't have an issue:
[root@freenas2 ~]# adduser /home/0day /usr/local/bin/bash
Username: 0day
Full name: 0 Day
Uid (Leave empty for default):
Login group [0day]:
Login group is 0day. Invite 0day into other groups? []:
Login class [default]:
Shell (sh csh tcsh bash rbash git-shell netcli.sh ksh93 mksh zsh rzsh scponly nologin) [sh]: bash
Home directory [/home/0day]:
Home directory permissions (Leave empty for default):
Use password-based authentication? [yes]: no
Lock out the account after creation? [no]: no
Username : 0day
Password :
Full Name : 0 Day
Uid : 8001
Class :
Groups : 0day
Home :
Home Mode :
Shell :
Locked : no
OK? (yes/no): yes
adduser: INFO: Successfully added (0day) to the user database.
Add another user? (yes/no): no
Goodbye!
[root@freenas2 ~]# su - 0day
[0day@freenas2 ~]$ id 0day
uid=8001(0day) gid=8001(0day) groups=8001(0day)
His failure to understand POSIX has shown up in the past as well: tmpfiles: R! /dir/.* destroys root #5644 with Pottering's amazing comment of:
I am not sure I'd consider this much of a problem. Yeah, it's a UNIX pitfall, but "rm -rf /foo/.*" will work the exact same way, no?
It's not like you couldn't take 5 seconds to test that:
root@m6700:~# mkdir /foo /foo/.test /foo/.test2 /foo/ .. .test .test2 /foo/.* /foo/ ..
root@m6700:~# touch
root@m6700:~# mkdir
root@m6700:~# ls -lah
total 12K
drwxr-xr-x 3 root root 4.0K Jul 29 14:04 .
drwxr-xr-x 25 root root 4.0K Jul 29 14:04
-rw-r--r-- 1 root root 0 Jul 29 14:04
drwxr-xr-x 2 root root 4.0K Jul 29 14:04
root@m6700:~# rm -rf
rm: refusing to remove '.' or '..' directory: skipping '/foo/.'
rm: refusing to remove '.' or '..' directory: skipping '/foo/..'
root@m6700:~# ls -lah
total 8.0K
drwxr-xr-x 2 root root 4.0K Jul 29 14:04 .
drwxr-xr-x 25 root root 4.0K Jul 29 14:04
How can Debian's developers justify using systemd, considering all of these unbelievably unjustifiable problems with it? Why have they subjected Debian and its users to these flaws? Is it really just a result of the best Debian users having long ago moved to FreeBSD, leaving around only users who don't know any better?
To be honest, not much of a difference in this case. When someone epically falls on multiple accounts with their response to horrendous bugs, I'd consider them to be the 'lamest vendor' Your post is overrated in that you're distinguish between something that has very little difference in this case.
Different goals of the platforms.
FreeBSD wants to be a well-rounded general usage OS
OpenBSD wants to be the pinnacle of security and is willing to throw everything out to achieve that goal
NetBSD wants to be ultra-portable
Dragonfly wants to be a high performance highly scalable and even distributed OS
Systemd dies if there is no cgroup support in the kernel.
/dir/.* destroys root.
/foo/.*" will work the exact same way, no?"
Poettering: "To make this work we’d need a patch, as nobody of us tests this"
R!
Poettering: "I am not sure I'd consider this much of a problem. Yeah, it's a UNIX pitfall, but "rm -rf
Processes owned by a user with a leading zero in the name are started with root privilege..
Pottering: "I don't think there's anything to fix in systemd here"
Systemd kill background processes after user logs out.
Poettering: "In my view it was actually quite strange of UNIX that it by default let arbitrary user code stay around unrestricted after logout."
'I have an issue with journal corruptions and need to know what is the accepted way to deal with them.'
Poettering: "Yupp, journal corruptions result in rotation, and when reading we try to make the best of it. they are nothing we really need to fix hence."
'Poettering locked and limited conversation to collaborators on 17 Apr'
What the fuck are you babbling about, schmuck? FreeBSD has an excellent binary package system with automatic dependency resolution: pkg. The user doesn't need to compile source from ports except if he wants something to be built with unusual options (same as linux, incidentally). All you need is "pkg install foo" and it will fetch the package foo and all its dependencies from the repo and install it.