7 ms·

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

95 points by jwilk 4y ago

sposeray 4y ago
[dead]
dijit 4y 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 4y ago
  Shouldn't a shell box just disable core dumps altogether?
- wizeman 4y 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.
- ajross 4y 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 4y 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.
    - ajross 4y ago
      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.
      - jeltz 4y ago
        Like your maximally uncharitable interpretation of the original comment.
        ajross 4y ago
        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.
        tremon 4y ago
        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?
_flux 4y 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.
- rwmj 4y 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.
- rollcat 4y 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/SystemdOomdNowDisabled 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 4y ago
    The systemd-oomd post discussed on HN: https://news.ycombinator.com/item?id=33894469 https://news.ycombinator.com/item?id=33894469 (2 weeks ago, 134 comments)
  - blueflow 4y 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.
    - CameronNemo 4y ago
rwmj 4y 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 4y 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 4y ago
Oh, that's nasty, using extended ACL have good chance someone will not notice it when looking at glance
htzag 4y 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 4y ago
  RedHat business is selling support, not making a usable operating system.
- pjmlp 4y ago
  There is a distribution for that.
pizzalife 4y 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 4y 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 4y 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 4y ago
  The Linux kernel is 30,000,000+ lines.
cryptonector 4y ago
Wow, this is pretty awful. Willfully defeating a security feature of the kernel.
scabros 4y ago
Maybe it's time to switch to Devuan, which is a systemd-free fork of Debian that works really well.

95 points by jwilk 4y ago

[dead]

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 4y ago
Shouldn't a shell box just disable core dumps altogether?
wizeman 4y 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.
ajross 4y 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 4y 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.
  - ajross 4y ago
    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.
    - jeltz 4y ago
      Like your maximally uncharitable interpretation of the original comment.
      - ajross 4y ago
        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.
        tremon 4y ago
        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?

_flux 4y 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.

rwmj 4y 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.
rollcat 4y 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/SystemdOomdNowDisabled 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 4y ago
  The systemd-oomd post discussed on HN: https://news.ycombinator.com/item?id=33894469 https://news.ycombinator.com/item?id=33894469 (2 weeks ago, 134 comments)
- blueflow 4y 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.
  - CameronNemo 4y ago

rwmj 4y 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 4y 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 4y ago

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

htzag 4y 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 4y ago
RedHat business is selling support, not making a usable operating system.
pjmlp 4y ago
There is a distribution for that.

pizzalife 4y 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 4y 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 4y 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 4y ago
The Linux kernel is 30,000,000+ lines.

cryptonector 4y ago

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

scabros 4y ago

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