On 6/1/23 10:12, Steve Grubb wrote:
Hello,
I want to add some missing information...
On Thursday, January 5, 2023 8:43:34 PM EST Ian Kent wrote:
On 6/1/23 09:17, Steve Grubb wrote:
I work on RHEL security problems. I have been looking into a number of
exploits and I think we have a problem that has an easy fix.
Here's some examples of what I'm look in at:
https://twitter.com/ETenal7/status/1506708119757328385
https://lkmidas.github.io/posts/20210223-linux-kernel-pwn-modprobe/
https://etenal.me/archives/1825
https://twitter.com/ky1ebot/status/1539820418479009792
https://github.com/theori-io/CVE-2022-32250-exploit
https://seclists.org/oss-sec/2022/q3/154
etc
We are not
using the CONFIG_STATIC_USERMODEHELPER_PATH kernel config option. There
are a number of exploits that overwrite the path to modprobe and then
pass something weird that causes modprobe to be invoked. But instead of
modprobe, it's their reverse shell.
If we make the assigment CONFIG_STATIC_USERMODEHELPER_PATH="/usr/" and
we change /proc/sys/kernel/modprobe to sbin/modprobe and /proc/sys/
kernel/core_pattern to lib/systemd/systemd-coredump %P %u %g %s %t %c %h,
then it limits any exploits to programs that are in /usr.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/
kernel/umh.c?h=v5.15#n371
Right, but the above description isn't quite how these config
options are meant to work.
To be maintainable in Fedora the way in which we utilize the bits
that are setup to do this type of thing would need to be inline
with the way they are intended to be used.
CONFIG_STATIC_USERMODEHELPER enables this,
CONFIG_STATIC_USERMODEHELPER_PATH allows you to specify the path
to the binary through with "all" usermode helper invocations are
done.
So we would need to write something that validates its own path
and the path of the thing to be invoked and, if all is ok, execute
the program.
The problem I see with this is that modprobe isn't the only thing
used with umh, there are a number of other things that use this so
some care is going to be needed in what is done and how it's done.
The idea of only allowing specific path prefixes sounds ok since
it's simple, fairly safe, umh kernel users really should be using
programs in "safe" locations, so this all sounds doable ... I'm
sure there will be a bunch of gotchas ...
Ian
Only root can
write here, therefore no escalation. Typically, an exploit changes
modprobe path to /tmp/ foo which is shorter than /usr/sbin/modprobe and
an area the attacker can control.
For this mitigation, we'd need to:
1) set the config option in the kernel build
2) update /proc/sys/kernel/modprobe however it's set
(CONFIG_MODPROBE_PATH)
3) update /proc/sys/kernel/core_pattern however it's set
If we fix the modprobe path issue, there are a couple other areas that
call usermode helper such as handle_initrd, fork_usermode_driver,
CONFIG_UEVENT_HELPER, and sbin/request-key which would need some touch
ups.
The benefit is a lot of privilege escalation attacks are taken away.
Does this sound worthwhile? Would people support this? Does this need to
be filed as a system wide change? Who could help make this happen if
approved?
It sounds worth while to me, ;)
Thanks for the initial vote of confidence. It's 3 am in Europe, so I'll wait a
bit for feedback.
-Steve
I'd be up for helping with it.
As much as I hate working in the proc file system I can try
and work out what needs to be done for the proc file system
bits.
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
