root can lift kernel lockdown
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
linux (Ubuntu) |
Fix Released
|
Undecided
|
Seth Forshee | ||
Xenial |
Invalid
|
High
|
Unassigned | ||
Bionic |
Fix Released
|
High
|
Unassigned | ||
Disco |
Fix Released
|
High
|
Unassigned | ||
Eoan |
Fix Released
|
High
|
Unassigned | ||
Focal |
Fix Released
|
Undecided
|
Seth Forshee |
Bug Description
SRU Justification
Impact: The kernel lockdown support adds a sysrq to allow a physically present user to disable lockdown from the keyboard. A bug in the implementation makes it possible to also lift lockdown by writing to /proc/sysrq-
Fix: Correct the logic to disallow disabling lockdown via /proc/sysrq-
Test Case: Write "x" to /proc/sysrq-
Regression Potential: Anyone using /proc/sysrq-trigger to disable lockdown will no longer be able to do so. Implementation bugs could prevent use of the sysrq from the keyboard from disabling lockdown, but this has been confrimed to still work with the fix in place.
---
Echoing "x" into /proc/sysrq-trigger disables kernel lockdown, even though it shouldn't.
If I'm not mistaken, kernel lockdown is meant to create a barrier between root and the kernel that can only be broken with physical access to the system. It is automatically enabled when the system is booted with UEFI Secure Boot, which is the case for me.
This should show the bug:
# echo "x" > /proc/sysrq-trigger
Nov 05 14:58:15 panzersperre kernel: sysrq: SysRq :
Nov 05 14:58:15 panzersperre kernel: This sysrq operation is disabled from userspace.
Nov 05 14:58:15 panzersperre kernel: Disabling Secure Boot restrictions
Nov 05 14:58:15 panzersperre kernel: Lifting lockdown
Note that it first says that the operation is disabled and then performs this operation.
This should only be possible by physically pressing sysrq+x on an attached keyboard.
I'm doing this on 4.15.0-68-generic on Ubuntu 18.04.3 LTS.
I have kernel.sysrq set to 1 - this is important to be able to trigger this bug. (But I don't think it disqualifies this issue as non-security relevant because root can trivially execute `sysctl kernel.sysrq=1`.)
I first learned about this by reading a blog post (https:/
Looking through drivers/
554 │ /* Ban synthetic events from some sysrq functionality */
555 │ if ((from == SYSRQ_FROM_PROC || from == SYSRQ_FROM_
556 │ op_p->enable_mask & SYSRQ_DISABLE_
557 │ printk("This sysrq operation is disabled from userspace.\n");
558 │ /*
559 │ * Should we check for enabled operations (/proc/
560 │ * should not) and is the invoked operation enabled?
561 │ */
562 │ if (from == SYSRQ_FROM_KERNEL || sysrq_on_
563 │ pr_cont("%s\n", op_p->action_msg);
564 │ console_loglevel = orig_log_level;
565 │ op_p->handler(key);
566 │ } else {
567 │ pr_cont("This sysrq operation is disabled.\n");
568 │ }
Note that `op_p->enable_mask & SYSRQ_DISABLE_
ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: linux-image-
ProcVersionSign
Uname: Linux 4.15.0-68-generic x86_64
ApportVersion: 2.20.9-0ubuntu7.8
Architecture: amd64
AudioDevicesInUse:
USER PID ACCESS COMMAND
/dev/snd/
/dev/snd/
CurrentDesktop: KDE
Date: Tue Nov 5 14:58:33 2019
InstallationDate: Installed on 2015-12-11 (1424 days ago)
InstallationMedia: Kubuntu 14.04.3 LTS "Trusty Tahr" - Beta amd64 (20150805)
MachineType: LENOVO 20E8S00600
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=
RelatedPackageV
linux-
linux-
linux-firmware 1.173.11
SourcePackage: linux
UpgradeStatus: Upgraded to bionic on 2018-07-05 (487 days ago)
dmi.bios.date: 09/26/2018
dmi.bios.vendor: LENOVO
dmi.bios.version: JHET69WW (1.69 )
dmi.board.
dmi.board.name: Intel powered classmate PC
dmi.board.vendor: LENOVO
dmi.board.version: SDK0E50510 WIN
dmi.chassis.
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.
dmi.modalias: dmi:bvnLENOVO:
dmi.product.family: ThinkPad 11e
dmi.product.name: 20E8S00600
dmi.product.
dmi.sys.vendor: LENOVO
CVE References
information type: | Private Security → Public Security |
tags: | added: patch |
description: | updated |
Changed in linux (Ubuntu Bionic): | |
status: | Triaged → Fix Committed |
Changed in linux (Ubuntu Disco): | |
status: | Triaged → Fix Committed |
Changed in linux (Ubuntu Eoan): | |
status: | Triaged → Fix Committed |
Hi Niklas - thanks for the bug report! After reviewing the lockdown lift via sysrq patch in 18.04 LTS (Bionic), I agree with your assessment. It looks like 19.04 (Disco) and 19.10 (Eoan) are also affected. Ubuntu 16.04 LTS (Xenial) is not affected.