Systemd-coredump: CVE-2022-4415: local information leak

https://www.openwall.com/lists/oss-security/2022/12/21/3

by jwilk • 4 years ago

95 50 4 years ago

openwall.com

dijit• 4 years ago

The normal way I use machines these days is that anyone with login access has some ability to become root.

But anyone who is hosting shellboxes (including "bastion" hosts in ISO27001 environments): this is pretty serious.

nine_k• 4 years ago

Shouldn't a shell box just disable core dumps altogether?

wizeman• 4 years ago

The normal way I use machines these days is that anyone with login access has some ability to become root.

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.

ajross4• 4 years ago

I'll bet you don't. The natural extension of that logic is that you don't bother with UID separation for running processes (since you don't believe it provides any protection), so for convenience all your software runs as root and all your ssh logins are directly to root, etc... No one does that, and I'll bet anything you don't either.

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.

yjftsjthsd-h• 4 years ago

> The normal way I use machines these days is that anyone with login access has some ability to become root.
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.

_flux2• 4 years ago

Quite disappointing someone would enable that kernel option without fully considering the ramifications :/.

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.

rwmj2• 4 years ago

I use systemd-coredump all the time on Fedora, it's pretty convenient. When a program crashes, run "coredumpctl gdb" to launch gdb on the latest coredump.

rollcat2• 4 years ago

systemd-coredump is vuln, systemd-oomd kills the wrong stuff, and you don't even learn that these programs exist (and are running on your system) until you find out from a CVE or a blog post detailing how to mitigate the problem[1].

[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).

jwilk• 4 years ago

The systemd-oomd post discussed on HN:

https://news.ycombinator.com/item?id=33894469 (2 weeks ago, 134 comments)

blueflow3• 4 years ago

You can turn the situation around: Pick some non-systemd OS, stick to it, and avoid software that does not run on it. You will end up with the old and boring tech, but it will be robust and run more reliable in the long term.

I've been running Alpine Linux in production for 4 years now.

kirbyfan64sos• 4 years ago

systemd-coredump is honestly incredibly useful. Any time an application randomly crashes in the background, you can easily pop it in a debugger to look through the backtrace without having to re-run it. Very handy for when the crashes are not easily reproducible, or you didn't expect something to fail and are not sure how to make it fail again.

ghostpepper• 4 years ago

As far as I can tell all the magic you're describing is provided by the kernel's core dumper and not systemd. You can achieve the same effect by creating /tmp/cores and setting a meaningful pattern in /proc/sys/kerne/core_pattern.

hansel_der• 4 years ago

coredumping crashed applications (or the kernel) was not invented by systemd

eqvinox2• 4 years ago

It's also incredibly annoying, because it changes longstanding cross-platform common behavior regarding this exact functionality. "A coredump is written to the crashing process's current working directory, named 'core' or 'core.<pid>'" - that used to be true on Linux and all the BSDs.

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.

jjav• 4 years ago

systemd-coredump is honestly incredibly useful. Any time an application randomly crashes in the background, you can easily pop it in a debugger to look through the backtrace without having to re-run it.

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?

bdhcuidbebe• 4 years ago

systemd-coredump is on my arch and i dont remember setting it up, anyway its rather cool, it even collects core dumps from podman

mhitza• 4 years ago

Fedora has it bundled by default. I've used it once, recently, to report a pipewire crash with bluetooth headphones.

rwmj2• 4 years ago

The exploit is quite interesting. Initially I didn't believe there could be a problem -- after all, we have the source of "su" so who cares if we can see a coredump from it? However the exploit is that "su" reads normally hidden files like /etc/shadow into memory (or more likely PAM does) thus exposing the contents of these files like password hashes to the non-root user.

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.

asveikau• 4 years ago

This reminds me of how several years ago Microsoft was found to be uploading mini dumps for the crash reporting service ... Using plaintext http. Probably fixed by now.

ilyt• 4 years ago

Oh, that's nasty, using extended ACL have good chance someone will not notice it when looking at glance

htzag• 4 years ago

When will RedHat learn that too many knobs and buttons, especially global settings, result in leaks and exploits? I don't care if the customers demand these.

I'm quite happy to enable/disable core dumps in the shell. Make Linux great again!

trasz3• 4 years ago

RedHat business is selling support, not making a usable operating system.

pjmlp2• 4 years ago

There is a distribution for that.

pizzalife• 4 years ago

Another day, another issue w/ core_pattern. Custom crash handlers have led to many local privilege escalations in the past. Don't use them!

bitwize• 4 years ago

How it started: [blog post from Lennart about the woeful state of Linux security and how systemd-newthingd fixes it]

How it's going: CVE-2022-4415

DiabloD3• 4 years ago

Obligatory comment that the only way to make a stable and well understood Linux system is to uninstall systemd, and shame on any distro that forces you to use this shambling corpse of a project.

xcdzvyn• 4 years ago

The Linux kernel is 30,000,000+ lines.

cryptonector• 4 years ago

Wow, this is pretty awful. Willfully defeating a security feature of the kernel.

scabros• 4 years ago

Maybe it's time to switch to Devuan, which is a systemd-free fork of Debian that works really well.

Systemd-coredump: CVE-2022-4415: local information leak

Related Stories