Create a user called '0day', get bonus root privs – thanks, Systemd! To obtain root privileges on a Linux distribution that utilizes systemd for initialization, start with an invalid user name in the systemd.unit file. Linux usernames are not supposed to begin with numbers, to avoid ambiguity between numeric UIDs and alphanumeric user names. Nevertheless, some modern Linux distributions, like …
This is classic Poettering. "I never make mistakes, if it doesn't work you must be doing something wrong". Too many of the Systemd "team" think the same way.
Does anyone remember this previous el Reg story? https://www.theregister.co.uk/2014/04/05/torvalds_sievers_dust_up/
Here's Linux Torvalds firing a torpedo at Systemd developer Kay Sievers after a Systemd bug made Linux systems unbootable and the Systemd "team" refused to fix it, saying that everyone else had to rewrite their code to work around it because Systemd was perfect:
"Key, [sic] I'm f*cking tired of the fact that you don't fix problems in the code *you* write, so that the kernel then has to work around the problems you cause," Torvalds fumed, adding that he wouldn't merge any more of Sievers' code into the kernel until he cleans up his act.
As we can see, nothing has really changed since that was written in 2014.
OK this guy sounds like the classic "My code is soooo precious" programmer but why do these (and only these) distros do this?
Does systemd do it to be compatible with them?
Under what circumstances is this behavior actually useful?
I can't think of a reason, other than some one cocked up development and others are playing follow-the-leader but is that the case?
It doesn't matter if it's useful or not, it's used in some distributions and systemd should be able to cope with it.
And someone at Red Hat should remind him who he works for and force him to open that bug again and fix it as otherwise it's a potential security problem on their own OS.
I remember trying to get support on the pulse audio mailing list - another of his fine creations, and being told (by Lennart) it was buggy alsa drivers that were at fault, not pulse audio so I should take up my problems with the alsa developement team.
The alsa drivers were obviously fine, the problem was in pulse (admittedly in an early incarnation) but the attitude was already there.
Could Poettering be an MS deep cover agent?
Lemme see... Buggy code with potentially significant security flaws? Check
Horrible attitude towards other? Check
Utter refusal to fix bugs? Check
Arrogant fuckwit who thinks he is God's gift rather than satan's diarrhea? Check
Nah, couldn't possibly be...
You left off the bit where Systemd looks and acts an awful (and I do mean Awful!) lot like the Windows registry; what with binary configuration files and logs that need the program itself to read them.
So if Systemd* crashes, it writes to a binary log, which requires Systemd* to load up to read the logs - What could go wrong?
*or the bits o' windows that read/handle the Registry
"So if Systemd* crashes, it writes to a binary log, which requires Systemd* to load up to read the logs - What could go wrong?"
Now, now... you just need to adapt to the new way of Linux'ing. No need to be critical ;)
It will only be a few months before the Samba stack gets imported into systemd and after that you can easily access those logs right after booting with your trusty Windows 10 environment.
This is a more generic problem in the open source community. People creating things as a hobby who just don't quite 'get' all those older principles us grey hairs used to live by and enterprises, anybody with a connection to the wild internet really, have to live by - like the principle of least privilege, like fail-safe over fail-soft (which may mean not being so forgiving about bad input!), like learning from the mistakes of others rather than continually choosing to repeat them yourself (to be fair this one is much more widespread than the FOSS community) and the list goes on.
implies Poettering is a clueless amateur, I take it. no argument from me!
I particularly dislike the use of 'exceptions' rather than checking return values. It's seems to be worse coming from the Python crowd...
It would be nice to run these clueless amateurs through a 'programming boot camp' where you ONLY get to code in 'C', and you MUST check buffer sizes and return values for things like "the file wasn't opened" and "attempting to overflow the buffer".
(and of course, check that the username is a VALID user name, and don't assume root privs when it's *NOT*)
yeah, I'd have a clue-bat, a clue-by-four, and a cat-5-o-nine-tails ready at all times
This post has been deleted by its author
Ehm, the rule of law started a little before. Hammurabi could tell something, and the Roman law formed the basis for the rule of law in Europe.
Universal human rights are a product of Enlightenment, medieval people and religions were fully satisfied with slavery, castes, sentencing free thinkers, etc. etc.
"Universal human rights are a product of Enlightenment"
Magna carta (1215) made such a good start at this that it took about 800 years before May managed to remove the concept of due process. The presumption of innocence didn't actually come from there but was introduced, I think from France, also in medieval times (maybe this is a further reason why May is in favour of Brexit - all these foreigners with inconvenient principles of law).
The presumption of innocence didn't actually come from there but was introduced, I think from France
I had a vague memory France had the opposite under Napolean Code, but a quick DuckDuckGo suggests I had this wrong.
Cool. Learned something new (or rather "corrected erroneous data in my head") :)
No, it's clueless return values which are from a medieval era. The "file was not open". Nice. But why it wasn't opened? Was it an RTL error? Was it an OS error? If it was an OS error, what was the original OS error? Do I have a chance to retry it, or not?
The issue with simple return values is they are "monodimensional" and may lose information along the way.
My best practice is "if you can add information to an error, but never remove from". So if a deeply nested routine encounters an OS I/O error, for example, it needs to pass this error to its callers, which may add more information, to allow the higher level one understand what it could do with the error.
Isn't not checking and acting properly on return values part of this very bug?
Yeah, I'm going to consider this a bad user ID so I'm not going to change to it, I'll carry on as root as I can't stop as I'm booting the system, so I'll just stick a warning in the log and hope that somebody reads it.
Later when somebody files a bug report...
ITS THERE BAD SOFTWARE!!!!11!11!1
I mean he works for the same employer that makes Red Hat (which considers it a good user ID), FFS.
The lack of exceptions if one of the reasons that makes C code so fragile and vulnerable. Even after you checked return codes you may have issue properly handling (i.e. freeing resources) and propagating errors without exceptions, usually needing a lot more fragile code and hacks (like gotos).
A small error, and code will keep on happily running in an unstable state, often creating exploitable vulnerabilities. There is also the need to propagate error information, with in C requires to use some static data somewhere, and additional "geterror" calls, hoping they were made thread-safe.
C++ didn't address the issue fully because of its obsession for RAII (which lead to the need of smartpointers - another hack needed to solve a design issue, but not everybody understands and use them properly). That's why we see lots of vulnerabilities around in C/C++ code.
Then there are many ways to use exceptions the wrong way as well.
But it's only amateurs that believe C is the perfect language, and it was creates as such.
Maybe he misunderstands the robustness principle
But I'm being far too generous there
" People creating things as a hobby who just don't quite 'get' all those older principles us grey hairs used to live by and enterprises"
Poettering isn't doing this as a hobby. AFAIK he's employed by Red Hat and Red Hat is certainly big enough to be classed as an enterprise.
A marvelous word. Truly captures the issue succinctly. Have an upvote and pint.
I'm inclined to upvote as well, apart from the reservation that it is not a strong enough word for this sort of f*ckwittery. It's the f*cking 21st century, failing safe should be now a programming reflex so that sort of attitude is not just wrong, it's actively disqualifying.
Have an upvote for "Twattitude", but may I also suggest such fine terms as "Ass-hattery" or "Douchebaggery"?
The venerable Reg term cockwomble has been used to describe the alleged developer, but I feel that an even more classic Reg-ism could apply: Twatdangle
What sort of crippled mind thinks it's OK to carry on and run if the user you're supposed to be running as is invalid?
Has the guy never heard of "failsafe"?
There are a whole range of options he had for how do deal with the situation - regardless of how it came about, whose fault that is - and he seem to have chosen the worst possible choice on the basis of 'not my problem'. Maybe it's not, but most decent people have a natural inclination to minimise the impact of mistakes made by others.
He's not exhibiting 'community spirit'. That's not compulsory but by choosing not to be 'with us' he sets himself 'against us' so it's not surprising he's often treated like a piece of shit.
"Has the guy never heard of "failsafe"?"
No. That's the worst thing you can think when the user fails to type his password correctly as the "failsafe" method is to let him log in anyway, thus rendering whole idea of 'security' meaningless.
All of it.
"Failsafe" has places and times but logins _are not either_.
"To exploit the issue, an attacker would have to convince an administrator – someone who already has root access – to install a unit file with an invalid user name. There may also be some risk in configurations where unit files are generated automatically."
I've already patched this one: I've asked all staff to refuse to engage with anyone on the blower asking them to create a systemd unit file line by line, character by character. I've also asked them not to click on anything thats looks like a systemd unit file in an email in Outlook or Evolution (for balance).
Witrhout getting into "poettering vs the world"...
Is "defensive programming" (together with "defense in depth") too ancient a concept for modern software 'design'?
E.g. don't trust input till you've safety-checked it yourself, or have very very good reason to trust what you're given.
Invalid input then ignore (or, perhaps equivalently, invalid user then abort) would seem more reasonable than the current behaviour (either of the code or of its author).
FWIW, POSIX doesn't say that a leading digit is disallowed.
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_437
"
To be portable across systems conforming to POSIX.1-2008, the value is composed of characters from the portable filename character set. The <hyphen-minus> character should not be used as the first character of a portable user name.
"
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_282
"
3.282 Portable Filename Character Set
The set of characters from which portable filenames are constructed.
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
a b c d e f g h i j k l m n o p q r s t u v w x y z
0 1 2 3 4 5 6 7 8 9 . _ -
"
So we can see that "0day" is a perfectly valid username.
It may be a bad choice for a username because it can expose bugs but it's _valid_.
(Fun: "1234" is a valid username... just imagine the chaos that'd cause!)
FWIW, Poettering doesn't count lack of POSIX compliance as of any consequence.
See: Cockwomble
FWIW, Poettering doesn't count lack of POSIX compliance as of any consequence.See: Cockwomble
https://lwn.net/Articles/430598/
His comments there reminded me of the browser wars fiasco.
Already, other systems are having to modify perfectly working standard code to be "linux compatible".
I'm sure it won't be long before we start seeing "This site best viewed in sysux"
Or error messages such as: "We see you are running xxx on a 96 core hypercluster. This server only supports systemd on an i486 or higher. Please upgrade to continue to use this site.
Baaah, I'm sure I'm not the only one who has at times been using top of the range hardware and software only for some site to obnoxiously tell me to "upgrade" to Internet Explorer 7. etc.
Quoting Poettering from that LWN article:
what we gain [by pissing all over POSIX] is a smaller chance to create bugsAnd how's that working out for you, Lenny?
On the other hand, the utterly delusional Poettering refuses to even accept bug reports, so I bet he genuinely believes it's working out great.
...it would increase the boot time of the servers? Having a fast booting server is the most important thing of all. It's more important than transparency. It's more important than security. It's more important than stability. This I know because Mr. Pottiecoder told me so.
It might be a remotely plausible argument (although not a good one) if there were in fact any evidence that Systemd booted faster than the alternatives. If there is any such evidence, I've not seen it yet.
If anything, Systemd seems to boot slower than any of the alternatives. Fedora was the first major distro to use Systemd, at which time they were by far the slowest booting major distro. When Ubuntu switched to Systemd, boot times increased very noticeably.
Whatever the advantages of Systemd may be, speed doesn't seem to be one of them.
Not sure if it is the init or just generally less cr*p started, but in any case systemd certainly doesn't seem to speed things up.
I haven't followed this much, but I'd like to know how systemd then became accepted as the core services mechanism? As far as I can tell, there seems to be an at best perceived advantage, and most sysadmins I know are conservative for a reason.
The perceived advantage is that a bunch if formerly separate components no longer function unless systemd is present, due to poettering et al rolling those components or similar functionality into systemd or infiltrating unnecessary dependencies within them. See udev, dns resolving and dbus for examples.
@Anonymous Coward - "I haven't followed this much, but I'd like to know how systemd then became accepted as the core services mechanism?"
Like Gnome 3, it was rammed down everyone's throats by Red Hat. Red Hat controls enough of the commercial enterprise Linux market that nearly everyone's applications have to be compatible with them. Once someone goes through the effort of creating a Systemd unit file, they may not bother creating or maintaining init scripts as well. Hence, any distro that wants to stick with another init system has to either do all the integration work themselves, or switch to Systemd. That's the reason that Debian switched, and once Debian did that, then Debian derivatives (such as Ubuntu) followed.
Another reason is that hard dependencies on Systemd were then written into other projects that Red Hat controls (e.g. Gnome 3, some of the new containerisation stuff, etc.). Getting rid of Systemd at this point is non-trivial, which is why many people thought the Devuan developers were biting off more than they could chew. BSD has been left out in the cold, since the Systemd developers refuse to accept patches which provide BSD support, and software which has traditionally been shared between Linux and BSD now won't work with BSD without a lot of patching due to these Systemd dependencies.
The basic concept behind Systemd isn't inherently bad. It's basically a copy of Sun's SMF init system (which was also copied by Apple). The actual implementation however seems dire. Everything is intertwined with everything else. NIH syndrome reigns supreme, with everything from logging to DNS being made an integral part of Systemd. The end result is that it's nearly impossible to replace a component of Systemd with something else, and the parts that are there are written by people who have only a superficial understanding of many of the problem domains covered and couldn't care less about anything their implementation doesn't fit.
When Systemd is eventually tossed on the trash heap, it will require a complete rip and replace of a lot of stuff since it's monolithic and can't be gradually replaced module by module. I suspect this was part of the design intent, to provide a high degree of project "lock-in"..
"Red Hat. Red Hat controls enough of the commercial enterprise Linux market that nearly everyone's applications have to be compatible with them."
They also still support just about the only enterprise Linux without systemd, RHEL6. So if you want to escape the stranglehold of one of Red Hat's least favoured contributions to Linux you can do so by becoming a Red Hat customer. That's irony or something.
I believe the "faster boot" bullshit was officially dropped by the Poettering cabal's propaganda division, once they discovered that this claim wasn't supportable with any actual evidence.
From the many conversations I've read on the subject, as far as I can tell, the sole reason for Systemd is that Poettering absolutely detests the fact that other distros are not Red Hat, refuse to adopt Red Hat's initscripts and various other distro glue, and therefore are a problem ... to Red Hat. But not to anyone else. Anywhere. Ever.
Obviously the solution to this non-problem is to mutate every distro into the bastard son of Red Hat, by "unifying" the init, and subsequently in the long term all distros, into a single Master Race distro, which for the sake of argument we'll just call "Red Hat".
This will then be followed by an intensive propaganda campaign in which choice is stigmatised as somehow being a bad thing, along with the perverted notions that war is peace, freedom is slavery, and ignorance is strength.
Then the book-burning ceremony begins, followed by tea and biscuits.
It's also a complete fucking waste of time on a server (well, a physical one anyways)
Look at how many minutes a Dell server takes to run its diagnostics and initialisation.
And then there's how long Cisco IOS takes to boot (and hell, that's got some Linux somewhere in there)
At the risk of getting a shed load of downvotes...
Don't you have to have root level access to put this file (with the dodgy name) in the right place to begin with?
If that is the case... oh wait. This is 'systemd' we are talking about.
That means...
The world will end tomorrow if this isn't patched and all systems updated with the next 10 minutes.
Phew, can I have some brekkie now that I have saved the world? :) :) :)
Random file corruption can and will happen. Flip a bit in the right place and now your unit file has an invalid username and will run as root rather than add the user it expects to run as. It is a remote liklihood, but would you want a process to suddenly, randomly gain root privs for no obvious reason?
Just because a user has permissions to create a file in a certain directory, doesn't mean that they should have rights to run a service as root on every boot. This is basically an escalation of privilege attack.
Although, I'll admit that an attacker would require quite a lot of privilege already to create the file, that's still no excuse for letting them run a service as root though.
Although, I'll admit that an attacker would require quite a lot of privilege already to create the file, that's still no excuse for letting them run a service as root though.
Aside from the random file corruption mentioned by the AC above, I can think of another way this could be exploited.
Sysadmin creates a file with this flaw while ghey are a sysadmin, you can even make it look like a typo' eg "9Proper_user" - as in "Oops, must have accidentally typed in that number when I was setting up this new system account for some-valid_reason using a very limited and inocent and non-exoploitable account.
When sysadmin gets fired some time later, there is an exploit on the system waiting to be exploited, and if found before firing can be made out to be a typo (like I'm doing a ton of since my latop died and I'm stuck with a tablet! :-( )
"To exploit the issue, an attacker would have to convince an administrator – someone who already has root access – to install a unit file with an invalid user name"
Would this not make it MORE of an issue?
Surly this allows me to chuck a sysadmin £20 and lets him do something that doesn't have his account details all over it to trace back to him
Actual hacking rather than the "kid in the hoodie in front of a green screen" image the daily mail has
No it doesn't make it MORE of an issue.
A good sysadmin will either have the system locked down and audit-able enough that making such a change would be traceable to him anyway, or they are sufficiently skilled to do whatever you're bunging them £20 for without being traced anyway.
While this clearly is a problem and there needs to be some way to mitigate it, there is a good argument for not doing so or at least not doing so by default.
What if there are environments where numeric users are being used intentionally (regardless of the fact they're invalid/unsupported) such as the idea of using employee numbers as another poster mentioned. Changing a fundamental behaviour of username handling that's been in place for years has a potentially huge impact, and when it's only exploitable by taking action as root in the first place we're really only a step or two away from saying "a root user being to give another user root access is a security flaw".
What this needs is an option flag that can be set in a config file to say "numeric usernames default access=" and the option to set root or user, and perhaps for now have it set to root by default, and in a few versions time switch to user by default.
Those that consider this a threat could then fix it now, those that don't have some time before they need to change any configuration.
More importantly I think you need to reassess the level of bribe you're offering, £20 is nowhere near enough to do anything that stands even the remotest chance of coming back on me.
Surly this allows me to chuck a sysadmin £20 and lets him do something that doesn't have his account details all over it to trace back to himActual hacking rather than the "kid in the hoodie in front of a green screen" image the daily mail has
That'd actually be bribery, or social engineering, rather than hacking ;)
"I understand this is annoying, ..."
... because there is a detectable error in the unit file and yet the system does not tell me about it.
"but still: The username is clearly not valid."
...so systemd feels free to make shit up and do that instead.
Sorry Lennart. This is not a security bug but it is definitely a bug, and a pretty embarrassing one at that.
> There seems to be a distinct lack of posts from angry systemd defenders in this thread. I wonder why.
We're waiting for one of you drooling systemd haters to hold Linus's spaghetti code to the same standards. I think we'll be waiting a long time.
https://www.forbes.com/2005/06/16/linux-bsd-unix-cz_dl_0616theo.html
Lok Technologies , a San Jose, Calif.-based maker of networking gear, started out using Linux in its equipment but switched to OpenBSD four years ago after company founder Simon Lok, who holds a doctorate in computer science, took a close look at the Linux source code.
“You know what I found? Right in the kernel, in the heart of the operating system, I found a developer’s comment that said, ‘Does this belong here?’ “Lok says. “What kind of confidence does that inspire? Right then I knew it was time to switch.”
"found a developer’s comment"
That is quite simply the stupidest reason I've ever heard for choosing not to use an OS. Comments like that are scattered throughout the source code of every OS I've ever worked on. All they are is memory joggers for the coder who wrote it. Suggesting otherwise says more about the ability of the commenter than it does the coder or the code base.
We're waiting for one of you drooling systemd haters to hold Linus's spaghetti code to the same standards. I think we'll be waiting a long time
Ahhh, the Poetterers are now comparing systemd to the kernel itself!
How long before we get a complete fork? sysdux? Poetterux?
Although the way the code is going, Poerrerdows would be more appropriate!
... but you have to admire the chap for his strongheaded consistency. As my colleague says "if you are consistently wrong, you are not wrong anymore!".
Well of course, this means that the distributions which use systemd are in the wrong. Which is why it is so important to support the few which do not!
I wonder will we get to a point in the future where Systemd becomes it's own operating system and splits from the Linux community?
I would shed a tear, but the sooner that bollocks Poettering stops being such a clown and takes his abomination systemd with him the better.
He really is the Yoko Ono of Linux.
"I would shed a tear, but the sooner that bollocks Poettering stops being such a clown and takes his abomination systemd with him the better."
I wouldn't and if he actually did split from the Linux community I wouldn't care whether he continued to be a clown or not. But an upvote for the general sentiment.
Alan Cox explained the problem in an interview once. He said (paraphrasing) that the great thing about LINUX is that developers aren't beholden to commercial constraints, someone can look at a piece of code and just think it's crap and re-write it from scratch for the sake of it. Unfortunately the opposite is also true and someone can also rewrite perfectly good code for no reason and wreck it.
Yes, it's an invalid user name.
No we don't allow user names with leading numbers specifically to stop them being confused with UID's
Yes it does have root privileges.
No we're not going to fix it. No stopping boot, no console warning. No limiting privileges.
IOW
No acceptance that systemd is at fault. No acceptance of responsibility (it's not systemd's problem). No willingness to see any other PoVs.
He's got the fast track to management written all over him, unless he p**ses off a senior enough PHB and gets shown the door.
I cannot imaging what he would be like to work with, other than a nightmare.
"He's got the fast track to management written all over him, unless he p**ses off a senior enough PHB and gets shown the door."
Can someone please pull their finger out and promote him before he does more damage?
Or if they did suggest this, I missed it.
Running the unit as root because the username is invalid is fucking stupid. So what are the alternatives?
1) Refuse to boot. Also stupid.
2) Run the unit under a special username that doesn't have privileges or a shell login or just about anything. Some people may recall the special user on most distributions called "nobody".
3) Worry that this attack might find some way of exploiting user "nobody" so create an even more crippled, brain-dead user than "nobody".
I think option 3 is the best. I suggest the username for this be "poettering."
4) Fail unit, log error, continue, fail anything that requires the failed unit <-------- there, that should be the behavior, makes sense ?
Note that systemd waits 90 seconds then refuses to boot if you have an entry in fstab pointing at a drive that does not exist! Obviously, this should ONLY be the case if / (root) cannot be found <---- that has been the behavior on UNIX since .... I dunno, some time in the 70's .... and Linux since fstab was introduced....
>For the same reason, a unit with User=nonexistinguser should fail instead of silently running as root.
That's exactly what happens, and what I wrote above: if the username is valid but the user doesn't exist we'll let the unit fail on start. If the username is already invalid syntax-wise we'll log about it but proceed.
Hence, if you write:
User=000fooo...@!
Then we'll ignore the assignment altogether (but log about it), since it's syntactically invalid. But if you specify:
User=waldo
and the user "waldo" does not exist (though it is syntactically valid), then we'll accept the setting, but as soon as you actually try to start the unit it will fail with "user not found". (Poettering, in the thread lnked-to in the article)
So,
user does not exist -> fail,
invalid username (according to systemd) -> use root
I think this says it all ....
The thing is, you can specify a regex for valid usernames ... I am not sure which other Linux software fails with a username starting with an integer, but it is possible to configure a system to accept them and create some ...
The other thing is, it is inconsistent, a unit will fail if it depends on an invalid service name, afaik.
Poettering knows he is wrong and he hates being wrong, if you try and explain the flaws in his logic he will pull the "this is not a philosophical debate" as he has so many times ... he ignores all software principles, such as principle of least surprise, because he and Kay are above all that, however, they keep forgetting that arrogance has to be earned ...
Ignoring bad configuration of systemd.units is wrong. Such units should not be attempted to start. Instead the exact reason why they are considered by systemd to be badly configured should be logged and nothing else done (in particular, no attempt to start).
Yes that means the packages which supply systemd.units which are not exactly right for any new release of systemd will have to be fixed. Yes, that's extra work for distributions, but they brought systemd upon their users, so they should also handle any breakage it causes.
Lennart Poettering, one of the lead maintainers of systemd, insisted the software is working as intended and declined to implement changes."I don't think there's anything to fix in systemd here," he wrote. "I understand this is annoying, but still: The username is clearly not valid."
Before reading it, I knew this would be his response.
He reminds me of those White House spokespeople justifying Trump (I think we are on the third right now.. Presumably the first two are dribbling in the corner of a room somewhere). All we need now is for systemd to start sending ridiculous tweets, and then he'll really start to shine.
...but I've never seen it in Unix / Linux before. (Provided I haven't touched one such system in 10 years, it would check out anyway, but I digress.)
Yet, people found the douchebag responsible for it under 42 femtoseconds. And then they got SURE he was a douchenozzle AND a douchebag that doesn't check boundaries on inputs whatsoever.
If it was a Windows Registry thingie we'd get "working as intended" blurted back by MS and then an obscure fix silently enabled on Patch Tuesday.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
