Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

openwall.com

Post reply on HN
Print view View original

31–40 of 52 posts

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

#31

Post by ajross »

jeltz wrote: post #27
ajross wrote: post #26

Earlier quoted context omitted.

That seems like a maximally uncharitable way of interpreting what I thought was a pretty uncontroversial point. The point was that when deploying software for use, best practice says "don't run it as root", and not "assume all software has root access". Do you really disagree? Because the grandparent poster definitely seems to, and I think that's pretty clearly wrong.

Like your maximally uncharitable interpretation of the original comment.

That still seems senselessly combative. I wasn't being mean, at least re-reading my comment it doesn't seem so to me. What's the deal here? Who did I offend, and how?

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.

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

#32

Post by pengaru »

eqvinox wrote: post #23
kirbyfan64sos wrote: post #16

Earlier quoted context omitted.

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.

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. '" - 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…

It's not like it was ever a safe assumption to blindly dump core to a process' CWD. It was just a convenient option in a developer-centric UNIX mindset, in lieu of anything better.

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.

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

#33

Post by adrian_b »

CameronNemo wrote: post #19
blueflow wrote: post #15

Earlier quoted context omitted.

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.

You will end up with the old and boring tech 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!

That's true.

I am using Gentoo with no systemd and with the latest versions of all programs that I am interested in.

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

#34

Post by 4khilles »

blueflow wrote: post #15
rollcat wrote: post #13

Earlier quoted context omitted.

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 st…

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.

Alpine's great. My entire homelab runs on it. Only complaint I have is its IPv6 support sucks. I have to hack together a bunch of scripts to get a reasonable network configuration.

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

#35

Post by Spivak »

pengaru wrote: post #32
eqvinox wrote: post #23

Earlier quoted context omitted.

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. '" - 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…

It's not like it was ever a safe assumption to blindly dump core to a process' CWD. It was just a convenient option in a developer-centric UNIX mindset, in lieu of anything better. 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…

I really don’t get why people are so quick to jump on “it changed so it’s bad.” systemd-coredump has to work in every possible case and is dealing with every unhappy path you can imagine. The kernel has a laundry list of situations where core files can’t be saved and systemd made the choice to set it up so some of the failure modes can’t happen.

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.

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

#36

Post by asveikau »

rwmj wrote: post #5

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…

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.

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

#37

Post by tremon »

ajross wrote: post #31
jeltz wrote: post #27

Earlier quoted context omitted.

Like your maximally uncharitable interpretation of the original comment.

That still seems senselessly combative. I wasn't being mean, at least re-reading my comment it doesn't seem so to me. What's the deal here? Who did I offend, and how? 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 think you were being mean, but you are being dense. This is the OP's statement:

> 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?

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

#38

Post by kelnos »

ajross wrote: post #31
jeltz wrote: post #27

Earlier quoted context omitted.

Like your maximally uncharitable interpretation of the original comment.

That still seems senselessly combative. I wasn't being mean, at least re-reading my comment it doesn't seem so to me. What's the deal here? Who did I offend, and how? 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 wasn't being mean, at least re-reading my comment it doesn't seem so to me.

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.

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

#40

Post by zajio1am »

blueflow wrote: post #15
rollcat wrote: post #13

Earlier quoted context omitted.

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 st…

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.

Note that musl libc in Alpine Linux has significantly smaller default thread stack size than glibc (128 kB vs 8 MB), therefore software developed and tested with glibc can easily crash with stack overflow.
Post reply on HN