Nasty Linux Systemd Security Bug Revealed (zdnet.com) 203
Qualys has discovered a new systemd security bug that enables any unprivileged user to cause a denial of service via a kernel panic. Slashdot reader inode_buddha shares the news via ZDNet's Steven J. Vaughan-Nichols: As Bharat Jogi, Qualys's senior manager of Vulnerabilities and Signatures, wrote, "Given the breadth of the attack surface for this vulnerability, Qualys recommends users apply patches for this vulnerability immediately." You can say that again. Systemd is used in almost all modern Linux distributions. This particular security hole arrived in the systemd code in April 2015.
It works by enabling attackers to misuse the alloca() function in a way that would result in memory corruption. This, in turn, allows a hacker to crash systemd and hence the entire operating system. Practically speaking, this can be done by a local attacker mounting a filesystem on a very long path. This causes too much memory space to be used in the systemd stack, which results in a system crash. That's the bad news. The good news is that Red Hat Product Security and systemd's developers have immediately patched the hole.
It works by enabling attackers to misuse the alloca() function in a way that would result in memory corruption. This, in turn, allows a hacker to crash systemd and hence the entire operating system. Practically speaking, this can be done by a local attacker mounting a filesystem on a very long path. This causes too much memory space to be used in the systemd stack, which results in a system crash. That's the bad news. The good news is that Red Hat Product Security and systemd's developers have immediately patched the hole.
Queue the inevitable... (Score:5, Funny)
Re: Queue the inevitable... (Score:5, Insightful)
All totally unjustified. The science is settled.
I mean...it's not like this is exactly the class of problems made possible by a piece of software that tries to do everything at once as opposed to multiple pieces of software siloed off from eachother in different address spaces.
Pish posh.
Re: (Score:2)
Re: Queue the inevitable... (Score:4, Interesting)
What "science is settled"?
While I agree this particular issue is no reason to hate on systemd in particular, there are many legitimate reasons to prefer other approaches over the systemd mess.
Re: (Score:2)
Dan J. Bernstein? That's a name I haven't seen in a long time. What an ego.
That was as stupid as the systemd "we're replacing everything else and re-enacting every bad idea Red Hat had for the last 20 years!!!"
And, again, ego ego ego.
Re: (Score:2)
I don't care one way or the other about YAML but this made me laugh. Pot, meet kettle.
Re: (Score:3, Insightful)
of course my init system should be the login manager and sync the time in an inferior manner to ntpd while losing logs and seizing up the system when boot trouble arises!
harumph! harumph!
Re: Queue the inevitable... (Score:5, Interesting)
And terminate background processes when you log out, with no record of having done so. That one was a surprise for sys-admins who used "nohup" to start background jobs and might lose their shell connection to a distant host.
https://linux.slashdot.org/sto... [slashdot.org]
Re: (Score:3)
More screen or tmux, than nohup, and it didn't actually go very far.
However it is highly instrumental in showing that Pottering has zero experience as an actual sysadmin.
Re: (Score:2)
I've been used linux on my work machine for ~20 years or so.
It just made sense, since I was mostly administrating linux servers.
There are things I have come to love about systemd. Particularly, though not only, on the laptop/desktop side.
It really has made linux quality-of-life on a personal machine lightyears better than it used to be.
On the server side, there are certain functions (regarding unit files) that also really have made things so much nicer-
systemctl restart openvpn@some-config
service openvpn restart
oh no
Re: Queue the inevitable... (Score:5, Insightful)
on every system you have. And then systemd complains endlessly that you're running a resolver that works, and it wants its broken one back or else!
Re: (Score:3)
To be fair, the standard nss resolver is pretty limited.
You can have some search paths and then a list of dns servers expected to resolve everything identically.
If you want to use a different DNS for 'myhouse.net' versus internet lookup versus 'workvpn.com' versus 'clientvpn.com', you have to set up your own dns server. Having that baked into a system resolver is nice. Though it is weird that you go through the nss code to query local dns meaning some work is needless/duplicated, but it's a more trivial pro
Re: (Score:2)
NSS implementation is generally lacking in feature set (though it could be extended- that's the damn point of NSS- someone just needs to write the damn code)
And so if you want some nice features of a modern resolver that you'd find in... well, any other operating system, you're left with resolved's attitude toward compatibility, where the maintainer's opinion of the RFCs for DNS are draconian and wrong-headed.
He seems to be able to read the rules on what is
Re: Queue the inevitable... (Score:4, Informative)
I have never written a shell script that had a problem with alloca(). I'm glad systemd went backwards to make that possible.
Re: Queue the inevitable... (Score:4, Informative)
GNU Bash has a long list of critical (many rated 10/10) vulnerabilities: https://www.cvedetails.com/vul... [cvedetails.com]
I'm sure other shells do too.
As for init systems there was some security through obscurity since people often had their own custom ones, but many also relied on the default scripts shipped by distros that sometimes had security flaws in them.
Re: (Score:3)
GNU Bash has a long list of critical (many rated 10/10) vulnerabilities
Yeah, and systemd left all those in, while adding a bunch of its own.
Re: (Score:2)
This "mistake" is only triggered intentionally. It's not something you will accidentally do.
This makes it akin to any of the multitudes of shell bugs that have turned into exploits.
Re: Queue the inevitable... (Score:5, Informative)
I mean...it's not like this is exactly the class of problems made possible by a piece of software that tries to do everything at once as opposed to multiple pieces of software siloed off from eachother in different address spaces
Well it would happen with anything PID 1, that's making the kind of call this program makes. The issue is unchecked alloca.
Like quick aside here, there's a roaming group of folk on Slashdot that are always like, "we don't need new programming tools, we just need better programmers". So this is one of those times those people need to chime in, because this same thing would happen if BSD mount was using unchecked alloca.
That said, the core issue is that PID 1 relies on alloca but doesn't check the input size. systemd-mount, which is what is calling for the mounting, reports the name back to PID 1 to "register" the mounted volume. The program systemd-mount and systemd itself are indeed different address spaces. unit_name_path_escape is calling strdupa (string dup with alloca) which alloca allocates bytes of memory up to ulimit -s size, because it pins the memory to the current stack frame. Now I'm sure one of our C brethren that are floating out there would yell, "Either use strndup or check the size of the char* before you send to alloca!!" And they would be correct...
Okay anyway, at the risk of making this a super sized comment. The point being, bad C code, not checking inputs, and code review failing at catching any of this. That happens with any piece of software. It isn't something unique to systemd. And systemd's style of handling things doesn't make it more prone to other processes sending BS to it to crash. Also, to trigger this, you need to mount something with 8MBs in the path name. That's a "mount -t ext /var/8mbofgrabage /blahblahblah" and that's not coming from the user, nor is that coming form udev. So why is someone allowing people from outside to mount on a box? But whatever, again, that's beside the point.
Now if someone wants to use this as evidence that the systemd team have no idea what they're doing or their code review is bunk. That's outside of the conversation I want to have since I have to have those kinds of talks with people at work. But point being is that if BSD mount had no check on a call to alloca, init scripts would fail if someone got an 8MB entry into your fstab, on reboot. And it wouldn't have to be mount, if there was an issue in BSD init that handled SIGHUP, and you SIGHUP a proc that's execution path was over the limit and for some dumb reason BSD was using strdupa in this call without first doing a check on the size, then you could trigger it on a kill -1. Now of course, BSD devs would have caught someone doing something as dumb as this and had them up on a pike, but the point being this is bad programmer and less bad design. Which don't get me wrong, I'm no fan of systemd design either, but let's put things into the correct boxes here.
Re: (Score:2)
So the init script managing mount/automount crashes. / is still mounted so the system is probably still functional-ish. init doesn't crash. Getty/login/sh shouldn't crash unless somehow they ended up in that directory. Updating boot0 might lose its shit. sysvinit, busybox init, and so forth... none of them *care* about mounts; they are a *user* problem. They don't track them, nor try to monitor which process is in which namespace: they give zero craps about anything except if there is a child process it nee
Re: Queue the inevitable... (Score:5, Insightful)
The point being, bad C code, not checking inputs, and code review failing at catching any of this. That happens with any piece of software.
No, it doesn't.
This is the case where the "bad programmers" argument is actually RIGHT. I know my students hated me during the C programming excercises, but they sure as hell learnt input validation. It took some of them 3 or 4 times being sent back with a segfaulted program to understand that it's not enough to check for whatever I put in the last time to make it crash, because I'll do something different the next time, and that they should ensure the input is what they expect.
Not validating your input does NOT happen to any piece of software. It's exactly what happens when you let bad programmers write kernel code, where no framework catches their mistakes.
Re: (Score:2)
Re: (Score:2)
I think "bad programmers" is just shorthand for "bad programming practices".
No, it's not.
Secure coding practices are a tool, a help - for both bad and good programmers. But bad practices and bad workers aren't the same thing.
That's why the programmers were "bad". Not because they created the bugs in the first place.
Good programmers create much fewer bugs. Not zero (nobody is perfect), but fewer. And since your code review isn't going to be perfect either, that matters.
Re: (Score:2)
That's complete bullshit. Security is my job, and bad programmers are one small part of the puzzle. If by magic all programmers were perfect tomorrow, I still wouldn't be out of a job.
"Well it would happen with anything PID 1" (Score:2)
No it wouldn't. Init is small, simple and does 1 task with a far smaller code attack vector and what code there is has been debugged for literally decades. If one of its child processes crashed the chances are the system would carry on albeit with some functionality missing that could be addressed by a sysadmin.
Re: (Score:3)
This is the kind of flaw that should be caught by static analysis.
For once Microsoft was on the right track here with deprecating functions that don't set size limits. The developer can still set the limit to some ridiculous value but at least it forces them to think about what the limit should be.
In fact for functions like alloca should really be deprecated for many reasons. Stack overflow is undefined behaviour, for example.
Re: (Score:2)
The point being, bad C code, not checking inputs, and code review failing at catching any of this.
Code review? In my Poettering-ware?
Re: (Score:2)
Well it would happen with anything PID 1
You clearly do not understand the issue here. Yes, of course it could happen withing anything PID 1. That is why whatever PID 1 is doing should be VERY LIMITED IN SCOPE.
This is exactly what all of the yelling and screaming was about and you dismiss it as: Of course it could happen with anything PID 1. Deaf and dumb.
Re: (Score:2)
That is why whatever PID 1 is doing should be VERY LIMITED IN SCOPE.
See people wonder why people are bad at C and this is why. So how fucking limited in scope should init be? Should it be so limited that you cannot pin allocation on top the stack frame? Hmm? Should there only be a subset of allocation methods acceptable to use in an init? Because any use of alloca() including strcmpa() would trigger this. In fact several of the GNU GCC specific allocation methods suffer from ease of corruption because it requires validating input.
you dismiss it as: Of course it could happen with anything PID 1
And this is why C is a dead language,
Re: (Score:2)
Maybe you should read the man page for alloca [man7.org].
Re: (Score:2)
Hey dipshit. Init does a lot more than that. What handles SIGINT, SIGPWR, and other signals? Just curious, how does an init transfer control on a tty to /bin/sh on a block device that isn't brought up? Shoot, if it's just scripts and what not, you should just init with a simple init=/bin/sh or worse case something in /sbin, go ahead fire that up let me know how that works for you. Oh also, what do you think manages state when you swap over on some other runlevel? Listens to events from anything brough
Re: (Score:3)
You don't use alloca() or VLAs, EVER. No more than gets(). And especially NOT when their length can be controlled by the user.
Yeah like I said in your other one, that's exactly the message that's getting lost in the "systemd is so complex" message.
Original person is like
That is why whatever PID 1 is doing should be VERY LIMITED IN SCOPE.
And it's like the scope isn't the issue. It's not understanding how memory allocation works that's the issue. Hence the reason...
Should it be so limited that you cannot pin allocation on top the stack frame?
Guy is so "Oh no! We're allocating memory in a complex project, we will surely fuck this up!" And I'm like, you can't do that. If you get too afraid to calloc or malloc or whatever, you're limited to stack and that's super shitty. D
Re: (Score:2)
how does an init transfer control on a tty to /bin/sh on a block device that isn't brought up?
It doesn't. It's your responsibility to make sure the block devices is up in your initrd/initramfs before transferring control to real init. /sbin/init is merely a shell script that runs the necessary commands to do initial bootstrap of the system before doing an exec() on real init.
On the simplest systems,
I get the distinct impression you don't actually understand the boot process of linux.
Re: (Score:2)
Actually if you read his entire comment he points out rather clearly that; an exploit like this in the conventional mount binary would be probably just as bad. It would result from the same kind of failure to check inputs/buffers, and it would still a privileged binary. RCE with root privs is what it is.
You are also not wrong that systemd being what is does offer a lot of extra footpint, and for issues like DOS it might take the blast radius from something very small to system wide. I am firmly in the syste
Re: (Score:2)
Actually if you read his entire comment he points out rather clearly that; an exploit like this in the conventional mount binary would be probably just as bad. It would result from the same kind of failure to check inputs/buffers, and it would still a privileged binary. RCE with root privs is what it is.
However, it's not, because mount is suid root.
It'd be more like if mount, instead of directly calling mount() by the kernel (which handled permissions for you) were actually handled by some kind of mountd process running as root, and then had its privileges and inputs validated by... significantly less competent individuals, who may even believe that certain mistakes are actually the right way to do something, and you just shouldn't send his daemon garbage.
Re: (Score:2)
There's a valid argument that the only reason our stupifying unvalidated alloca() exists within PID1 (in such a way that accepts arbitrary fucking input from anyone on the system) is due to poor design of an init system, where PID1 really needs to avoid doing... well, anything that can cause it to crash, as in terms of system stability, a failure of PID1 is as grave as a fai
Re: (Score:2)
No marginally competent C programmer would ever use alloca() or variable-length arrays in the 21 century.
That's the entire point I was trying to make. Thus far everyone keeps blaming that the reason someone fucked up memory allocation is because systemd is a needlessly complex project and I keep telling them, no, if you're bad at C, then it doesn't matter if the project is complex or not. That's what all those "many lines of pretentious confusing shit" sum up to. Except I don't add never because there are cases where you'd like alloca, but if a coder is worth their salt, they understand what goes on behind
Re: (Score:2)
But also wrong.
But you're right- they should be commended for the former attributes.
I know very much about the code underneath. I've been writing linux system software for 2 decades.
Your mention of homed and such indicates to me that you don't really understand the problem here.
Having systemd-homed as separate is largely pointless when it requires IPC with PID1 to do its work, meaning the vulnerability (either to exploit, or simple errors) exists in PID1. You're relying on t
Re: Queue the inevitable... (Score:2)
I don't know why this was modded as troll as there are valid points here regarding constant updating. Maybe it's the wording.
Me, I am tired of the constant updating, especially forced updating. Recentky I was riding in an Uber, and I looked over to the center console screen and saw a message that said something along the lines of "You cannot use the music player now because it hasn't been updated.", a real WTF moment for me as I still don't expect to see messages like this in a vehicle infotainment
you mean something like ... (Score:4, Funny)
initctl start hate target=systemd
Re: Queue the inevitable... (Score:2)
Re: (Score:3)
Re: (Score:2)
Re:Queue the inevitable... (Score:5, Insightful)
Practically speaking, this can be done by a local attacker mounting a filesystem on a very long path. This causes too much memory space to be used in the systemd stack, which results in a system crash.
If you have a local attacker able to mount a filesystem on your machine you have bigger problems than this particular bug.
Re:Queue the inevitable... (Score:5, Informative)
I have some bad news for you. FUSE has existed for quite a while now and allows exactly this.
Re:Queue the inevitable... (Score:4, Interesting)
Then welcome to systemd based automounting of attached media, and the popular defaults that enable automounting of NFS shares on request. Automounting is a commonly mishandled issue.
Re: (Score:2)
Then welcome to systemd based automounting of attached media
Obviously the systemd devs looked at the successful history of automount/autoplay under Windows and thought "yep, that's a winner, gotta get me some of that for Linux...".
Re: (Score:2, Troll)
Then welcome to systemd based automounting of attached media
Obviously the systemd devs looked at the successful history of automount/autoplay under Windows and thought "yep, that's a winner, gotta get me some of that for Linux...".
Well, you joke but that is the story of systemd: copying everything that is wrong with Windows because the developers have a severe inferiority complex and want to make things work the way the big boys do it.
Luckily, my Linux system doesn't use systemd.
Re:Queue the inevitable... (Score:5, Informative)
Then welcome to systemd based automounting of attached media
Doesn't work like that. You actually need to create a path name that is larger than 8MB in size. SystemD doesn't automount anything like that because there's no device that would present to the system like that (and if it did you'd have bigger problems). And to automount NFS you need the user to specifically set it up (and if they did, you'd have bigger problems).
You can't abuse automount to trigger this bug if you don't have access to the config of the machine.
Re: (Score:2)
What did they do, mount War and Peace?
/s
Re: (Score:3)
Then try this on your system as an unprivileged user:
mkdir tmp
sshfs user@remote: tmp
Re: Queue the inevitable... (Score:2)
Invest in a lock and key, and a good solid door. That will really help with your peace of mind.
Totally predictable (Score:5, Insightful)
The one bit of systemd code that I inspected replaced a bash script in the old init system with vanilla C code that only did string manipulation - nothing binary. Why? Those string functions have more holes than a slice of Swiss cheese. What caused the current nasty security nightmare? A string function.
Re: (Score:3)
What caused the current nasty security nightmare? A string function.
Nope. It was alloca() returning error if given a 1Gb path (one GIGABYTE long path). The kernel also can't handle this well and panics anyway.
Re:Totally predictable (Score:5, Informative)
> one GIGABYTE long path
Hrm? The disclosure says 8MB:
Either way, Debian folks look here: https://security-tracker.debia... [debian.org]
Re: (Score:2)
>>Nope. It was alloca()
The article that I read said that the bug was introduced by a programmer who:
"... replaced a strdup() in the heap with a strdupa() on the stack."
So the programmer was replacing a POSIX string function with well-defined behavior with a non-POSIX string function that called alloca, which lacks said well-defined behavior. So I guess we are both right. The real problem, though, is that it appear to be that there is no process control on the programmers of systemd - make use of wha
Re: (Score:3)
I saw that this morning when there were a lot of pending updates on my machine, and the changelog description for most of them said little more than "don't use strdupa()". I was thinking: WTF? I didn't even know there was a strdupa() function. Everyone knows that you shouldn't ever use alloca(). Does it call that in turn?
I looked up its manpage, and the answer is yes, this nonstandard GNU-specific extension does call alloca().
The fact that this high-profile mission critical project had such a blatant blunde
Re: (Score:2)
"dupa" means "ass" in Polish. That's all you need to know about this function.
Re: (Score:2)
I hate panics. Ruins my system uptime bragging rights.
Uptime bragging is still a thing?!
Re: (Score:3)
No, the kernel does not panic over alloca. The kernel doesn't even get involved in alloca, it's purely an adjustment to the stack pointer in the process. If the program tries to alloca more space than the stack has, the next code that touches the stack will likely trigger SIGSEGV, killing the program. In this case, systemd.
This absolutely points to a serious design flaw of systemd as well as a bug. The bug is using alloca having no idea if there is enough room on the stack for the request or not.
The design
Re: (Score:2)
The old SysV init is written in C, and it does not share this fail. If init even cares about something you mount after the system is up, it's too complex. That should be another daemon's problem.
The first improvement would be to make systemd something that is run by the old /sbin/init (systemd could be a replacement for /etc/init.d/rc for example). The varous other things systemd does like name resolution, time, user session management, etc should be standalone programs that are execed as needed.
Re: (Score:2)
Re: (Score:2)
You're kinda getting warm but you mangled the details anyway, so you're kinda an idiot.
Re: (Score:2)
A strdupa instead of a strndupa. String functions aren't the issue per se, unbounded string functions are. Just never do that.
Re: (Score:3, Insightful)
You have a sarcastic morning again?
What are the chances that a guy who is not able to read the doc of a simple string function is able to write his own string "library" that is safer?
Bottom line it is anyway the fault of the "we are archaic programmers cult". Why the funk does anyone call a function strdupa()? Before it even starts to make sense, you need meta knowledge about 3 things: str means string, oki, so far so good. Dup means duplicate, can accept that. And what the funk is "a" supposed to mean? Sur
Re: (Score:3)
What are the chances that a guy who is not able to read the doc of a simple string function is able to write his own string "library" that is safer?
Good question. I should amend my statement.
To anyone who can't/doesn't read the docs: stop programming now.
Re: (Score:2)
Why anyone wants a string to be duplicated onto the stack is beyond me anyway. Why not just pass the original string?
When you want to modify the string (in a minor way, so len remains same); eg say change 'foo.bar' into 'foo/bar'. May be you want to use such strings temporarily (in the function) eg use in debug messages; And you don't want to bother using say malloc/free pair (as that introduces the chance of a mem leak if you forget the free in some code path).
Re: (Score:2)
A memory leak won't immediately crash the process.
Re: (Score:2)
What are the chances that a guy who is not able to read the doc of a simple string function is able to write his own string "library" that is safer?
Easy, his code that very few use wiill not be impacted by a well-known CVE. He will brag about how this move avoided some big problem in the industry. Then the moment an actual security person gets a hold of his implementation, then he'll have a problem, but by the way security is commonly scored, he does pretty well by not being affected by common industry CVEs.
Meh (Score:5, Interesting)
As a card-carrying cranky old recovering sysadmin I get as excited as anyone about the latest systemd faceplant. Because in my day we had sys v and bsd init and we liked it. We liked it just fine.
But I digress. This isnâ(TM)t even that big a stumble. Itâ(TM)s a little egg on face at worst for the team, itâ(TM)s no big deal for shops who do security right (principle of least privilege and defense in depth notifications it at least twice over), and itâ(TM)s potentially a hassle for admins of multiuser systems with malicious or capricious users.
Now, if it were remotely triggerable that⦠(is it? I only read the summary. Or, you know. Glanced at it). Iâ(TM)d have a good chuckle over that one. Because Devuan and the various BSDs all exist and are viable choices. Or unikernels, even.
Re: (Score:2)
As a card-carrying cranky old recovering sysadmin I get as excited as anyone about the latest systemd faceplant. Because in my day we had sys v and bsd init and we liked it. We liked it just fine.
So with you on that.
When I read about systemd my first thought was "isn't that the OPPOSITE of how a Unix system works? You know, make small pieces that do one job and do it well, then make them talk to each other?"
But hey, like 5 years from now someone will come up with something novel like a domain concept or subsystem framework to split the monster into smaller parts, for stability and security reasons. Then they'll invent a new virtual filesystem to access those subsystems. Then they'll spend a decade o
Re: (Score:2)
When I read about systemd my first thought was "isn't that the OPPOSITE of how a Unix system works?
Depends on how you think your UNIX system works. I assume you don't actually do anything with your system, i.e. run a GUI. God knows there's nothing Unix philosophy like about any of the current GUIs out there. Nor are many of the programs we use UNIX for.
Do one thing and do it well is all good and fine if that one thing is actually useful. There's a reason every man and their dog attempted to replace sysv init, while it did its one thing well, blindly executing a program while throwing a PID state file int
Re: (Score:2)
I assume you don't actually do anything with your system, i.e. run a GUI.
Two of my Unix systems run a GUI. My server, of course, doesn't.
God knows there's nothing Unix philosophy like about any of the current GUIs out there.
X was closer to the original philosophy, yes. But it's still less monolithic than Windows.
Nor are many of the programs we use UNIX for.
A lof ot the ones I use are. But yes, it depends on what you do with your system. And anyway we weren't talking applications, but system-level.
There's a reason every man and their dog attempted to replace sysv init
There's also a reason they all failed.
Re: (Score:3)
Re: (Score:3)
Shut up Lennart.
Re: (Score:2)
Why do you like it? How do you use it?
Re: (Score:2, Interesting)
There was a real need for changes, to support the kinds of things you mention, not to mention improving support for containers.
It simply never followed that a single, universal, monolithic, ever-expanding, memory-unsafe behemoth like what systemd started out as - much less what it has since become - was the right solution.
In fact, it never followed that there had to be a single, universal solution at all.
With the advent of systemd, mainstream Linux (Debian or RedHat based) has become a monoculture, and that
Re: Meh Tragedy of SystemD on youtube (Score:2)
It won't change, sadly. Redhat wants linux to be a monoculture.
It's a fact that the mess of multiple solutions for the same problem that was the linux ecosystem was both its greatest strength and biggest issue.
We wouldn't run linux on everything from a toaster and a cow milker to supercomputers and our home computers without it.
We should have way less trouble finding relevant information about configuring our networks without it. And maybe we should have reached "the year of Linux desktop" if it was a monoc
"Systemd is used in almost all modern Linux dist" (Score:2)
Almost, not mine...or so I thought. This makes me want to cry, being FORCED to use systemd (even a part of it) just to get standard software to work:
https://alien.slackbook.org/bl... [slackbook.org]
This will be Slackware-15 (-Current er currently). What to do?
Re: (Score:3)
Re: (Score:2)
Re: (Score:2)
There are lots of systemd-free Linux distros. See wikipedia:
https://en.wikipedia.org/wiki/... [wikipedia.org]
Re: (Score:2)
There are lots of systemd-free Linux distros. See wikipedia:
As with much of Wikipedia this seems a little out of date (at least only a little!).
As AlienBob discussed in the blog, ELoginD is has to be integrated to get PAM & even parts of KDE to work, replacing ConsoleKit. Even though elogind is supposedly "cleaned and sanitized" and clean-forked from systemd-proper, its a little un-nerving.
On "nosystemd.org" it also still shows Slackware, so I may be over reacting; I hope so. Interestingly, Parabola is shown as well.
As for the suggestion of OpenBSD (or any BSD)
Failure to follow past peactice (Score:5, Insightful)
Re: (Score:2, Troll)
It allows Poettering to massage his ego and justify his job.
F'n idiots (Score:2)
Fucking idiots. Never heard of strndup? (Or in this case, strndupa)
Nobody should ever use strdup. Ever. Go sit in the corner now.
Re: (Score:2)
You have a situation here where crashing on bad input allows a DOS attack. So if you can't mount a filesystem with an 8MB path, and you can't respond by crashing, the best you can do is log an error and make sure that your code does effectively nothing on an attempt.
Re: (Score:2)
strndupa could be similarly bad, as they probably weren't being mindful of this specific limit. The problem is stack corruption resulting from large alloca, whiich strndupa would happily do, given a large enough constraint. Or, alternatively, if the function might be inlined by compiler optimization and called many times in a 'calling' function, in which case even a small alloca could create issues. Here the string was properly allocated and properly terminated, it was just too big to be suitable for someth
Re: (Score:2)
Well, no, strndup(input, PATH_MAX) would be a bad call by itself (note not strndupa, but strndup), because the result is silently corrupted through truncation. If it's just something to display, then silent truncation may be appropriate, but if you are actually using that data for something meaningful, then having a silently truncated copy can be very very bad.
Putting that aside, the suggestion that strndupa(input, PATH_MAX) would be fine is also bad. It may be in practice not a problem in this specific sc
So the problem is (Score:3)
Re: (Score:2)
Should alloca() be Considered Harmful? I had vaguely heard of it before, but wasn't familiar with it because I don't use it. Now that I have read about it, it seems to be another argument in favor of C99, this time because of Variable Length Arrays. Too many people out there are still using "C89 with // comments", despite it being over 30 years old. (And yes, C99 is 20+ years old, but later enhancements are much less fundamental.)
https://stackoverflow.com/questions/1018853/why-is-the-use-of-alloca-not-con [stackoverflow.com]
Thank goodness (Score:2)
Linux securty? (Score:2)
LOL... slashdoters have been huffing your own farts for so many years.
Re: (Score:3)
What are you blathering on about? It was the many eyes that found the bug.
Try to find bug reports of Linux systems randomly crashing in the wild. You won't. Because the many eyes found this, not the black hats.
Re: (Score:2)
I'd guess that there are 10x more Linux kernels running at this moment than Windows. (Remember Android, containers, VMs, etc.). Even on Microsoft Azure, Linux images reportedly outnumber Windows images. Linux is a WAY bigger target. It has been probably for 10+ years.
But for this and many other reasons, some of them rooted in culture, others in architecture and design, and still others resulting from incompetent coders:
Systemd hugely increases the attack surface, makes Linux less secure, and should NEVE
Re: (Score:3, Insightful)
If anyone who criticizes your community is a paid shill of !community, then your community is an unhealthy paranoid shitfire. Don't let FOSS descend to the levels of Q-Anon, Wokescolds, and Shitcoin.
Re: Another blow for "many eyes" (Score:4, Insightful)
Re: (Score:2, Informative)
Why was he modded troll? Ah, mod disagreed with his conclusions? I disagree, too, but blah blah and blah...
Because he's an idiot. And so are you. Exactly opposite to his thesis, the black hats didn't find this, the many eyes did.
Re: (Score:2)
AFAIK, you can't easily escape systemd if you use a Debian- or Red Hat-based distro.
I do avoid it, by using Gentoo, and there are other ways as well, for those sufficiently familiar with the Linux command line; however, I'm not aware of any systemd-less distributions that target relatively nontechnical end users.
Re: (Score:2)
fusermount is setuid root to enable users to mount userland filesystems.
Re: (Score:2)
And yet, they overwhelmingly are able to in most default distribution configurations. An argument can be made that with the wide availability of mount namespaces, an unprivileged user should be given their own namespace and only be able to affect that, but ultimately I think users need to be able to mount filesystems so long as that doesn't entail being able to throw unsanitized filesystem directly at kernel code. E.g. most kernel filesystems may not be hardened against malicious filesystems, but the fuse