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.

Comments

Already been closed

[NoNonAlphaCharsHere]

Marked NOTLAME, WONTACCEPT, closed.

Also, lameness filter.

Re:Already been closed

[AmiMoJo]

I know I've defended Poettering in the past, but lately I've come to think that he is a right pillock. systemd badly needs somehow who understands security and who can get these issues the attention they deserve.

Re:Already been closed

[Anonymous Coward]

Too bad there isn't some other init system that has been tested for decades and is rock solid we could use instead... Wait! there is!

Re:Already been closed

[Anonymous Coward]

Seriously though, why the Debian tag? Surely Redhat would be more appropriate in the circumstances?

Re:Already been closed

[arglebargle_xiv]

Too bad there isn't some other init system that has been tested for decades and is rock solid we could use instead... Wait! there is!

smss.exe? Will that run under Linux?

Misleading title

[markdavis]

>"Systemd Named 'Lamest Vendor' At Pwnie Security Awards"

I have no great love of Systemd, but that headline is misleading. The award was the "lamest vendor RESPONSE." But, you know, it is all the rage to have intentionally misleading headlines to grab even more attention than deserved.

Re: Misleading title

[whitlocktj]

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.

Re: Misleading title

[Anonymous Coward]

Remote root compromise isn't serious? I have never, I mean ever, seen anyone hunker down and suck so quickly and enthusiastically as Zero__ does on Poettering, and I'm homosexual.

And yes, that is one of the four bugs listed. Any confusion in linking the bugs to the appropriate CVE is, again, entirely Poetterings fault and part of the reason he got the award.

Re: Misleading title

[Zero__Kelvin]

No. A remote exploit can be found in a lot of software. It would be horrendous if it was obvious or they refused to fix it, but neither of those things are true.

No words.

[0100010001010011]

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
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/0day
Home Mode :
Shell : /usr/local/bin/bash
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
root@m6700:~# touch /foo/.test
root@m6700:~# mkdir /foo/.test2
root@m6700:~# ls -lah /foo/
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 .test
drwxr-xr-x 2 root root 4.0K Jul 29 14:04 .test2
root@m6700:~# rm -rf /foo/.*
rm: refusing to remove '.' or '..' directory: skipping '/foo/.'
rm: refusing to remove '.' or '..' directory: skipping '/foo/..'
root@m6700:~# ls -lah /foo/
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 ..

Re:No words.

[Anonymous Coward]

It is almost as if the concept of "be conservative in what you do, be liberal in what you accept" is useful in graceful handling of errors. I mean, not as if someone said it in the past who had any importance.

Re: No words.

[aardvarkjoe]

Except of course that this very bug has been fixed for weeks now, as havevall tje other bugs listed.

Yes and no. They did fix the security problem by having the unit file error out if the username starts with a digit. So at least they're no longer randomly running things as root.

But they still haven't fixed the problem that systemd won't accept valid usernames. As far as I can tell, that is 100% an ego thing -- they won't admit that having systemd have its own username validation rules is a mistake.

Re: No words.

[aardvarkjoe]

What the FUCK are you talking about? Never mind, you made it pretty clear you don't know.

Another quality post from our resident Poettering fanboy!

You want to enlighten us as to what part of my post you think is wrong, so I can correct you?

Re: No words.

[aardvarkjoe]

Again, systemd does the safe and sane thing here.

Let's see -- systemd's incorrect username validation caused a privilege escalation here. Yeah, real safe and sane, guys.

The actual correct implementation -- permit any username that the system allows to be created -- suffers from no such problems. As such, it is the safe and sane thing.

Re: No words.

[0100010001010011]

I tried CentOS. I went to the source.

I downloaded the latest ISO they had. I did a fresh clean install.

It let me use 0day as the install user.

http://imgur.com/a/8PZcS

It then allowed me to login with it. With zero problems.

It then allowed me to do this:

[root@centos ~]# cd
[root@centos ~]# adduser 1day
[root@centos ~]# adduser 2day
[root@centos ~]# useradd 3day
[root@centos ~]# useradd 4day
[root@centos ~]# id 1day
uid=1001(1day) gid=1001(1day) groups=1001(1day)
[root@centos ~]# id 2day
uid=1002(2day) gid=1002(2day) groups=1002(2day)
[root@centos ~]# id 3day
uid=1003(3day) gid=1003(3day) groups=1003(3day)
[root@centos ~]# id 4day
uid=1004(4day) gid=1004(4day) groups=1004(4day)
[root@centos ~]# uname -a
Linux centos 3.10.0-514.el7.x86_64 #1 SMP Tue Nov 22 16:42:41 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
[root@centos ~]#

So now I know you're full of shit. Name one distribution that does that, let alone a 'most'. Fuck at this point take a screenshot of any OS throwing an error trying to add a 0day user. You piqued my interest enough to download OpenIndiana and see what Solaris thinks.

but if you read the bug you would already know that adduser and useradd disagree on the acceptability of said username

No, I read what Pottering said. But time and time and time again his actual knowledge of how things work is completely wrong (See the rm -rf /foo/.*).

Systemd is turning out to be the Theranos of Linux with Pottering at the helm sounding more and more like Elizabeth Holmes every day. It's like he makes it up as he goes.

Re:No words.

[TCM]

You completely misunderstand what "be liberal in what you accept" means.

It doesn't mean to take any input and cherrypick single bits that you understand and ignore the rest. You rather try to parse inputs liberally, while making sure it's unambiguous in its meaning. For example, when parsing a config file, there could be more whitespace than necessary. As long as you find valid keywords in that extra whitespace, you're good to parse it liberally. When writing a config file, however, you're supposed to trim all that whitespace to a uniform scheme.

You would also be free to ignore invalid keywords to support forward compatibility.

What you shouldn't do and what being liberal doesn't mean is saying "this input would be correct to me if I threw away these letters in the keyword". That's just retarded.

How does Debian justify using this?!

[Anonymous Coward]

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?

Re:How does Debian justify using this?!

[Anonymous Coward]

It was shoved down Debian's throat by the technical committee in a first ever usurp of power from the developers to the committee. There was not consensus on this change at all.

Re: How does Debian justify using this?!

[Anonymous Coward]

Not only that but the vote for Systemd in Debian was a 2-2 tie and had to be overruled. Hardly a "everyone wanted Systemd" that a lot of the pro-systemd people like to suggest.

Re:How does Debian justify using this?!

[Anonymous Coward]

I think that there was no consensus is what caused the technical committee to get involved. Many people were advocating for a next generation init system to replace SysV. Clearly forcing maintainers personally support all possible init systems would be worse.

The decisions that came down from the technical commitee made systemd the default init (#727708) and required that maintainers at least accept contributions for other init systems (#746715). The outcome provided for another popular system init to be supported if developer interest was great enough even if the package maintainer advocated for something else.

It's worth noting that systemd is compatible for SysV init scripts so really if the maintainer already supported SysV then they likely already had working support for systemd.

Re: How does Debian justify using this?!

[Tenebrousedge]

Rating: pants on fire.

Re: How does Debian justify using this?!

[somenickname]

You are correct, it was 8 people that voted on it and, as per the "pants on fire" link (https://lists.debian.org/debian-ctte/2014/02/msg00402.html) it was a 4-4 tie. That tie was decided by Bdale Garbee. Bdale Garbee made the decision to switch to systemd. Frankly, Mr. Garbee should be forced to hand over his Greybeard Card. He has shamed our honourable order.

Re:Should systemd be rewritten in Rust?

[HanzoSpam]

If I hear of a company marketing a supported enterprise distro of FreeBSD, I'm gonna buy stock!

Re:Fuck linux and systemd

[Anonymous Coward]

FreeBSD is superior in many other ways too: Performance, ZFS (a category of its own), packaging, stability, kernel code quality. I only use Linux now when I have to (like some SoC vendor with piles of Linux only drivers).

Xinuos OpenServer 10

[Anonymous Coward]

So it sounds like you want Xinuos OpenServer 10:

Xinuos OpenServer 10 is a 64-bit operating system based on the popular FreeBSD and designed to support business applications within an enterprise environment.

It should be noted that Xinuos also offers SCO UnixWare and SCO OpenServer. Even sco.com now goes to their web site. What's funny about this is that it wasn't SCO that ultimately harmed Linux to the point of it being unusable. It turned out to be the Linux community itself that made Linux unusable by including systemd! And now it is what could be seen as a successor to SCO that's providing relief from how the Linux community has ruined Linux!

What a world we live in!

Re:Xinuos OpenServer 10

[unixisc]

An interesting aspect of this is that Xinuos, as the successor to SCO* - the company that inherited UnixWare and w/ it System V Unix IP, has decided to fork off FreeBSD - a BSD project - instead of continuing on System V. That really demonstrates that the System V branch of Unix is for all practical purposes dead. Xinuos just does support work on the legacy SCO Unixes, but beyond that, drives companies towards FreeBSD. Oracle just supports Solaris on legacy SPARC hardware, but otherwise, pushes Oracle Linux. All the other Unixes that were based on System V are dead.

Re:Xinuos OpenServer 10

[unixisc]

Actually no! Tarantella was acquired by Sun shortly after it spun off SCO, and it didn't have the OSs - it had some utilities like IIRC OpenVision and some NFS like software.

Xinuos was the successor company to SCO, Inc, after it filed Chapter 7. They inherited whatever legacy assets SCO had, as well as any customers, but started w/ a FreeBSD fork for enterprises. No idea whether their management has anything in common w/ that of SCO, Inc.

I seem to remember Miguel de Icaza ...

[HBI]

Back in the days when Mono was considered a submarine way to give Microsoft control over Linux, there was such universal hate then.

Why not OpenBSD?

[Ungrounded Lightning]

Use FreeBSD, no systemd and technically a truer Unix than linux anyways.

Why do you mention Free rather than Open? (Or Net, for that matter?)

Seriously: I was looking at porting a project from Ubuntu 14.04 LTS to OpenBSD rather than later Ubuntu releases for security (and licensing) - at least in part because 14* to 16* or later means going to systemd and trying to security audit it looks like a nightmare. The obvious candidate was Open, because of its security tightness and because it's just supporting one embedded app on one particular hardware platform, so not having the whole kitchen sink of drivers and apps isn't an issue.

Is FreeBSD just a better match for what you're doing? (Laptop?) Or is there something else I should be looking at when picking a distribution?

Re:Why not OpenBSD?

[Anonymous Coward]

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

Re:Why not OpenBSD?

[Curupira]

OpenBSD is undoubtedly safer, but FreeBSD is generally considered to be updated more often and better to use as a desktop/laptop OS. In fact, there is TWO desktop-centric operating systems based on FreeBSD: TrueOS (formerly PC-BSD) and DesktopBSD. So, if your intent is to use it in a desktop/workstation, FreeBSD is probably a better fit.

Re:Why not OpenBSD?

[hord]

I've run Open and Free. Here is my opinion:

FreeBSD - Stable and ultra fast on x86 hardware. Good for file servers, desktops, anything.
OpenBSD - Stable but not performant. Useful for infrastructure.

I really like OpenBSD. I ran it for many years and even contributed hardware to the project. That being said, the security features in it don't outweigh its performance drawbacks. Some of this is due to the security features (e.g. PID randomization slows process generation) so your choice will be workload dependent. Your hardware choices with Open will be more limited as well and you don't get stuff like ZFS. I'd experiment with both.

Re:Why not OpenBSD?

[Anonymous Coward]

That's the public consumption stuff.

OpenBSD is really Theo's vehicle, which he forked out of spite after getting into a stupid spat with NetBSD core@. (This says bundles about both, incidentally.) They do worship "security" (and it often does devolve into "worship", though they do know their stuff) but to value it properly you need to understand their idea of "security", which is actually pretty narrow. Point in case: "openntpd", which is written by security nerds because the reference implementation was deemed to be doubleplus ungood, and not by time nerds. So you get a situation where the thing only doing sntp is deemed peachy fine. Except that to people who really need Proper Time, the bread and butter of ntp, this is simply not good enough, but the thing won't tell you. Fun times.

NetBSD is a bit of a tinker toy. It's pretty portable, but some (even non-mainstream!) platforms are actually better served by, oh, OpenBSD or something. It is a bit hampered by its core@ being a bunch of nice people and by its niche status. It now has lua in the kernel.

FreeBSD is a different kind of tinker toy with a big position as "geheimtipp" for servers, something they've done their level best to destroy since FreeBSD 5, first with the n:m scheduler (which they finally gave up on with FreeBSD 8), and now with various userland rewrites, including pkgng (which suffers from a massive case of second system effect). It was traditionally strongest on i386 and now x86_64, and much less so on other platforms (alpha was somewhat decent, though). There is a strong influx of linux refugees, and it shows.

DragonFly BSD is Matt Dillon's fork of FreeBSD 4.11, because he disagreed with the n:m scheduler as overly ambitious (which got vindicated) and as a vehicle to do things like HAMMER with. Too bad the thing also saw fit to jump the pkgng bandwagon. Like NetBSD it suffers from being small-ish and being niche without having a clear niche-crowd to leverage.

They all have their own flavour and they all steal from each other with gay abandon.

So you see, the people behind it are important also, certainly if you'd like to participate and not "just use". And the best way to learn about them is to try.

So if interested do find the time to install each of them at least once, even if only as a VM. But do install from scratch; go for a bootable system without X and packages, then build from there.

One thing the *BSDs tend to do much better than linux is documentation. So be sure to look for that first and do plenty reading before starting your installs.

With all this hate...

[Kokuyo]

I've been considering switching from Ubuntu to something without Systemd. But what would that be? Slackware is a bit hardcore and frankly, I'm really scared I won't get my server functional ever again if I start from scratch...

Re:With all this hate...

[sconeu]

What about Devuan?

Re: With all this hate...

[thePjunisher]

I tried Devuan, but too early, maybe, because I found the beta I tried to be barely functional. It might be better now. In the end, I landed on Manjaro OpenRC.

Re:With all this hate...

[aardvarkjoe]

Most of those who oppose systemd are pining for the Good Old Days of loading the boot target using bat-handle toggle switches on the front of their IMSAI.

We're mostly pining for the Good Old Days when you could trust your init system to do what it was supposed to do.

Re:Should systemd be rewritten in Rust?

[fahrbot-bot]

If bugs and programming errors that result in security flaws are a problem with systemd, would rewriting it in a language like Rust help?

There are bugs, programming errors and bad programming. Don't confuse the three.

why are distributions using it ???

[cats-paw]

Never have I read anything positive about systemd.
and what I've read about it's design is extremely non-unixy.

so why did any of the distributions pick it up ?

Thus Spake Poettering ..

[khz6955]

Systemd dies if there is no cgroup support in the kernel.

Poettering: "To make this work we’d need a patch, as nobody of us tests this"

R! /dir/.* destroys root.

Poettering: "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?"

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'

Re:Thus Spake Poettering ..

[xbytor]

> "In my view it was actually quite strange of UNIX that it by default let arbitrary user code stay around unrestricted after logout."

Wow. Really, just wow. I am so happy I don't have to use Debian or any of those other systemd distros.

Re:Thus Spake Poettering ..

[dindinx]

If you don't compile network support into the kernel, no http servers can work. If you don't compile cgroup support into the kernel, systemd is the only init system that can't start. Every other init starts with no problems.

See the différence?

That suspicion isn't like the systemd issues

[jbn-o]

I recall that being an entirely different issue from what's at issue in this /. thread. This thread concerns possibly buggy free software in need of some maintenance and review. Microsoft's patent licence for .NET core is a threat of a different kind—Microsoft's patents covering software in Mono and licensing that doesn't grant users the freedoms of free software work together to grant Microsoft the power to extracting patent royalties from free software distributors.

Re:Fuck linux and systemd

[fnj]

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.

Trojan horse?

[pkphilip]

I wonder if systemd, pulseaudio etc are trojan horses inserted into the Linux ecosystem for nothing else but screwing things up - they work, sort of, but not very well.. they are irritating enough to significantly reduce the adoption of Linux and also to slow down the overall development of the Linux ecosystem by focusing attention on problems which could have been easily avoided. There there is of course these security vulnerabilities which open up in the strangest of places.

Of course, I have no evidence for this, but it has been a nagging suspicion.

Re:Trojan horse?

[gweihir]

I believe that is the case, but Poettering is not clued in. It seems likely that Linux became too hard to hack into, so something needed to be done. Putting a known incompetent with a huge ego and no understanding of security in charge of a critical central system component is just the ticket to do that. And it will not look like a sabotage attack either, because said incompetent will screw up security all by himself, whit zero understanding of how he is being used.

The nature of the campaign that systemd was pushed with gives further indication for that: Zero arguments technical merit, except on the meaningless surface. As soon as anybody tried to go into actual technical arguments that matter, emotional appeal, deriding of the person, portraying them as "backwards" and "anti innovation", etc. This just means that there were no good technological arguments, but a group with access to PsyOps techniques really wanted it to be pushed hard. And look where we are, they basically succeeded. Of course, PsyOps only works against incompetents long-term and there is still a core of the Linux community that actually understands technology, as exemplified by this award and the continuing resistance. Technological facts do not go away.

Re:Bobby Drop Tables

[0100010001010011]

At this point I'm not unsure that Zero__Kelvin isn't Pottering's slashdot account.