Bug 87354

Yep. The question is whether we should attempt to sandbox (seccomp?) and drop privileges, or use a special user, or have multiple special users to do this? The first option seems nicest.

(In reply to Zbigniew Jedrzejewski-Szmek from comment #1)
> Yep. The question is whether we should attempt to sandbox (seccomp?) and
> drop privileges, or use a special user, or have multiple special users to do
> this? The first option seems nicest.

I can't say I have any particular opinion on which technology to use for this.

(In reply to Bastien Nocera from comment #0)
> If a process running as root crashed, systemd-coredump would change the
> effective uid/gid to that of the crashing program.
> 
> So a carefully crafted coredump could hit elfutils parsing bugs to run
> arbitrary programs as the same user that crashed.
> 
> The solution would be to avoid running elfutils code as any privileged user.

Hmm?

We generate the stack trace after dropping uid/gid to the same as the process that crashed.

If you managed to carefully craft a coredump under some uid/gid, then you are so powerful, why would you then still need to trigger a bug in elfutils?

If you make apache crash inserting enough data into apache to craft the coredump the way you want, and then acquire access to the apache user that way, what have you gained? I mean, you could just as well run your code as apache user right away, no need to go via the coredump stuff...

Not following here, why there would be any new threat by the coredump logic?

I have been thinking a bit about this since some friendly fuzzers helped find some issues in elfutils. See https://bugzilla.redhat.com/show_bug.cgi?id=1170810

The first thing to do if you are worried about this issue should be upgrading to elfutils 0.161 which contains lots of hardening patches. See https://lists.fedorahosted.org/pipermail/elfutils-devel/2014-December/004481.html

I think comment #3 is mostly correct. The core dump/stacktrace is generated with the uid of the crashing process. Given that someone could make the process crash in the first place they could probably do much worse. Trying to then take advantage of the fact that other code then runs with the same uid seems to be a lot more work than trying to take advantage of the original way to crash the process in other ways.

An attack that takes advantage of the fact that a core dumper is running does need to somehow also trick the core file generated to contain an issue that triggers a bug in core parsing code. That probably requires a bug in the kernel code that generates the core data. The core dumper, through elfutils, also accesses other files, either directly because they were executable files mapped in the process or indirectly because those files contain build-ids that refer to separete debuginfo files. Those files will be parsed if addresses on the call stack refer to the mapped in executable files.

So an attack would require making the process crash, and either triggering a bug in the kernel that generates core data that is not parsed correctly or manipulating the (call) stack to contain a reference to mapped in executable ELF data and/or a build-id reference to a debuginfo file that is under control of the attacker to trigger an ELF/DWARF parsing bug.

It seems somewhat unlikely that the above is true and the attacker can crash the process, but not manipulate the process more directly. But it still couldn't hurt to drop even more priviliges while processing the core data and generating the backtrace. As long as the original ELF files and debuginfo data files can be accessed.

Triggering an assert or segmentation fault can often be done relatively easy. I don't know what kind of bugs elfutils might have, but I image that something like an overlong function argument could lead to some issue. Both of those things can imaginably be under attacker control. It is a basic security in depth thing — we should try to make it harder to escalate. Running elfutils as root with privileges should be avoided.

As a first step I have now changed the coredump tool to drop all caps before processing the coredump.

http://cgit.freedesktop.org/systemd/systemd/commit/?id=f11943c53ec181829a821c6b27acf828bab71caa

We might want to take this a couple of steps further:

* introduce a new user "systemd-coredump" or so, and if we process a coredump for root, drop privs to that user. There's one complexity about this though: ideally we'd make sure that the SCM_CREDENTIALS structure passed to journald for the coredump is the root user then, and not "systemd-coredump".

* move the src/core/namespace.[ch] to /src/shared, and make use of it here, to protect the root directory and home, like we do for normals services.

All that together should be a sufficiently good sandbox.

PR #2555 now moves the coredump processing into a service of its own, so that the kernel core_pattern hook process only collects some metadata and the immediately passes off everything to a process maintained as systemd service, that is locked down using systemd's resource management and sandboxing. it now lives in a network namespace and similar things.

The tool now also drops privileges to become the "systemd-coredump" user while processing coredumps, but only for system user processes. For normal user processes it becomes the uid of the crashing process, which I think is the right approach. 

I think this kinda settles this bug, closing.