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