* Paul Wise <p...@debian.org>, 2019-03-13, 08:54:
The majorly broken thing is, unfortunately, the Linux kernel. It does
argument splitting only _after_ it expanded the macros.
I think that this is a bug in the Linux kernel that needs to be fixed,
would you mind sending either a bug or a patch for this issue?
Yes, I think this is something that should be ultimately fixed on the
kernel side.
I looked briefly at the source (fs/coredump.c, grep for
"format_corename" and "argv_split"), but unfortunately it's not trivial
to fix. I'm afraid my kernel fu is too weak to write a patch.
I might file a bug at some point, but feel free to beat me to it. :-)
If the executable name contains spaces, you will get more than 2 or 3
arguments. On kernels that don't support %d, this allows an attacker
to control the "owner" variable.
On a second thought, the faked owner would always start with pid, uid,
gid and so on... There's not much damage you could do this way. The
worst you could is to pollute /var/crash with bogus root-owned
directories.
I think I can workaround this using this core pattern:
kernel.core_pattern = |/usr/lib/corekeeper/dump %u %d --
%p-%u-%g-%s-%t-%h-%E.core
The core pattern and the dump executable will be out-of-sync at least
for a brief moment during upgrade (possibly much longer if the user
modified the conffile and kept the old one on upgrade), so it's
desirable to keep the original order of arguments.
We could append or prepend a character to %d to make sure the argument
won't disappear after %-expansion, for example:
|/usr/lib/corekeeper/dump +%d %u %p-%u-%g-%s-%t-%h-%E.core
Keeping the number of arguments (almost) constant should also make
parsing easier.
--
Jakub Wilk
