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