Systemd-coredump: CVE-2022-4415: local information leak
openwall.com
openwall.com
I wonder if it would be generally better for su/PAM to mark this data as non-dumpable (MADV_DONTDUMP), just for defence in depth. You could also imagine coredumps being uploaded in bug reports, unintentionally revealing sensitive data.
Do some distributions use systemd-coredump by default? I not just learned about systemd-coredump and I'm wondering if it could be actually useful for develoment purposes; apport doesn't seem to be.
Several setups of ours rely on that fact, and since we're developing software that is supposed to work on Linux and {Free,Open,Net}BSD, we were happy to be able to reuse a bunch of crash-capture logic.
systemd kneecapped us out of the blue, it took us some time to figure out where the coredumps were going. Now we disable systemd-coredump on all systems. Which works, except when something reenables it or we add a new platform and someone forgets to disable it. Sigh.
Yes, we can deal with it, by disabling it. But crash captures went from being reliable to "did systemd-coredump creep back in?" - a definite regression.
Sometimes daemons run with a CWD changed somewhere rarely if ever written to at runtime, and presumed to primarily contain information intended for sharing. It's not hard to imagine a security-conscious daemon that's done both chroot() and chdir() into a path intended for publishing information out of, and not generally intended for the daemon to write into except by privileged users/publishers.
When that daemon spuriously dumps core into its CWD now you have potentially sensitive information sitting in the published tree, e.g. maybe the credentials of the privileged users are in that core file.
If they just tried to write to cwd there would be a blogpost about “systemd loses coredumps if your app directory is read-only” which isn’t some theoretical problem, it’s containers.
There was no way to really win here.
That's not actually the issue here. Rather: "it changed so now it's inconsistent across platforms"
> There was no way to really win here.
There is:
- if you're changing a multi-platform standard, include the other platforms (e.g. create a coredumpctl tool for *BSD)
- do the changes slowly/incrementally in a backwards-compatible way (e.g. apply the new coredump locations first to read-only containers and service daemons running as systemd units)
- The BSD are irrelevant. Why hamper Linux development to cater for users who don't exist?
It isn't as if it worked the same everywhere anyway.
At least in Debian and Ubuntu systemd-coredump is a separate package (and wasn't installed by default for me atleast), so I expect you can just remove it and it doesn't get automatically enabled in any way.
Have you tried masking it? (https://www.freedesktop.org/software/systemd/man/systemctl.h...)
coredumps are of course incredibly useful, as they have been for decades. Couldn't live without them.
Is systemd adding any value here other than making things more complex and brittle?
[1]: https://utcc.utoronto.ca/~cks/space/blog/linux/SystemdOomdNo...
And then, there are very few alternatives, because more and more software requires systemd (and even if most things still don't, so much stuff requires glibc so Alpine or OpenBSD aren't always very good as alternatives).
I've been running Alpine Linux in production for 4 years now.
Not always. I have sway and pipewire running smooth as can be on my systemd-free workstation. As well as recent releases of Linux, glibc, Mesa, and Firefox. All the essentials are there and up to date for me!
I am using Gentoo with no systemd and with the latest versions of all programs that I am interested in.
https://news.ycombinator.com/item?id=33894469 (2 weeks ago, 134 comments)
But anyone who is hosting shellboxes (including "bastion" hosts in ISO27001 environments): this is pretty serious.
That is good, but you don't necessarily need login access to exploit this. You could exploit it via an RCE vulnerability in some other program, like the HTTP server or NTP client.
In fact the Unix uid/gid does provide real security value in practice. It is not absolute, and relative to other barriers commonly used (LSM, cgroup containers, VMs, firewalls, BPF syscall filtering, etc...) it's comparatively weak and porous. But it's not something to dismiss either.
The nature of "defense in depth" security analysis is that you have to embrace that depth and not throw bits out. UID separation has the distinct advantage of being dirt simple to understand and extremely cheap to deploy. Use it.
> I'll bet you don't
I'll... bet they do? You realize that description most trivially matches "I give people sudo access", right?
So they say they do something and you promptly say that you don't think they do that, because "nobody" does a more extreme version of the same idea that they never suggested? That's a classic straw man.
To repeat a third time: don't run stuff as root simply because you assume root elevation exploits exist. I stand by that, and don't really think anyone here disagrees.
I don't have a dog in this race, but you started your comment with "I bet you don't", which, to me, is unnecessarily combative and/or snarky. Right out of the gate I was predisposed to think ill of whatever you had to say.
I guess I should have quoted. My apologies for seeming "snarky", but the conversation you read isn't the one I was engaged in.
But let me repeat for a fourth time that you shouldn't be running processes as root, whether or not you have worries about undiscovered vulnerabilities and especially regardless of whether you are "predisposed to think ill" of the people telling you that.
UID separation isn't a perfect model, but it's a good one, and you should use it.
> anyone with login access has some ability to become root
If you take that to mean "I run all my software as root", then you're being maximally uncharitable. And when people point out to you that your interpretation isn't the only one available (nor the most logical one), you accuse others of being senselessly combative?
I'm quite happy to enable/disable core dumps in the shell. Make Linux great again!
How it's going: CVE-2022-4415