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

41–50 of 52 posts

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

#41

Post by eqvinox »

Spivak wrote: post #35
pengaru wrote: post #32

Earlier quoted context omitted.

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 “syst…

> I really don’t get why people are so quick to jump on “it changed so it’s bad.”

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)

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

#43

Post by blueflow »

4khilles wrote: post #34
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.

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.

I had no trouble with IPv6. For static config i add it to /etc/network/interfaces, for dynamic config i use dhcpcd without issues.

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

#44

Post by jjav »

kirbyfan64sos wrote: post #16
_flux wrote: post #4

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.

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.

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

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

#45

Post by mhitza »

_flux wrote: post #4

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.

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

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

#46

Post by ajross »

kelnos wrote: post #38
ajross wrote: post #31

Earlier quoted context omitted.

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.

FWIW: the grandparent has editted the comment to remove the framing I was responding to (something along the lines of "root access is inevitable"), which explains why everyone is being so outrageously touchy.

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.

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

#48

Post by pjmlp »

eqvinox wrote: post #41
Spivak wrote: post #35

Earlier quoted context omitted.

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 “syst…

> I really don’t get why people are so quick to jump on “it changed so it’s bad.” 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…

Forgetting about Aix, HP-UX,....?

It isn't as if it worked the same everywhere anyway.

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

#49

Post by pjmlp »

htzag wrote: post #10

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!

There is a distribution for that.

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

#50

Post by WastingMyTime89 »

eqvinox wrote: post #41
Spivak wrote: post #35

Earlier quoted context omitted.

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 “syst…

> I really don’t get why people are so quick to jump on “it changed so it’s bad.” 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…

- It's not a multi-platform standard more a happy accident of history.

- The BSD are irrelevant. Why hamper Linux development to cater for users who don't exist?

Post reply on HN