root can lift kernel lockdown

Bug #1851380 reported by Niklas Sombert on 2019-11-05
262
This bug affects 1 person
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Status tracked in Focal
Xenial
High
Unassigned
Bionic
High
Unassigned
Disco
High
Unassigned
Eoan
High
Unassigned
Focal
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-trigger.

Fix: Correct the logic to disallow disabling lockdown via /proc/sysrq-trigger.

Test Case: Write "x" to /proc/sysrq-trigger. When working properly there should be no messages in dmesg about lifting lockdown, and lockdown restrictions (e.g. loading unsigned modules) should remain in effect.

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://gehrcke.de/2019/09/running-an-ebpf-program-may-require-lifting-the-kernel-lockdown/), so I'm not the first to notice this behavior (even though this post doesn't say it's a bug).

Looking through drivers/tty/sysrq.c, I guess the problem is caused by this if condition in __handle_sysrq:

 554 │ /* Ban synthetic events from some sysrq functionality */
 555 │ if ((from == SYSRQ_FROM_PROC || from == SYSRQ_FROM_SYNTHETIC) &&
 556 │ op_p->enable_mask & SYSRQ_DISABLE_USERSPACE)
 557 │ printk("This sysrq operation is disabled from userspace.\n");
 558 │ /*
 559 │ * Should we check for enabled operations (/proc/sysrq-trigger
 560 │ * should not) and is the invoked operation enabled?
 561 │ */
 562 │ if (from == SYSRQ_FROM_KERNEL || sysrq_on_mask(op_p->enable_mask)) {
 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_USERSPACE` just causes a printk and no change of behavior.

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: linux-image-4.15.0-68-generic 4.15.0-68.77
ProcVersionSignature: Ubuntu 4.15.0-68.77-generic 4.15.18
Uname: Linux 4.15.0-68-generic x86_64
ApportVersion: 2.20.9-0ubuntu7.8
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC1: niklas 2442 F.... pulseaudio
 /dev/snd/controlC0: niklas 2442 F.... pulseaudio
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=/@/boot/vmlinuz-4.15.0-68-generic root=UUID=67485aa6-c665-4c53-bf41-328307d0cbf0 ro rootflags=subvol=@ quiet splash kaslr i915.alpha_support=1 vt.handoff=1
RelatedPackageVersions:
 linux-restricted-modules-4.15.0-68-generic N/A
 linux-backports-modules-4.15.0-68-generic N/A
 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.asset.tag: Not Available
dmi.board.name: Intel powered classmate PC
dmi.board.vendor: LENOVO
dmi.board.version: SDK0E50510 WIN
dmi.chassis.asset.tag: No Asset Information
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: None
dmi.modalias: dmi:bvnLENOVO:bvrJHET69WW(1.69):bd09/26/2018:svnLENOVO:pn20E8S00600:pvrThinkPad11e:rvnLENOVO:rnIntelpoweredclassmatePC:rvrSDK0E50510WIN:cvnLENOVO:ct10:cvrNone:
dmi.product.family: ThinkPad 11e
dmi.product.name: 20E8S00600
dmi.product.version: ThinkPad 11e
dmi.sys.vendor: LENOVO

Niklas Sombert (ytvwld) wrote :
Tyler Hicks (tyhicks) wrote :

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.

Changed in linux (Ubuntu):
status: New → Triaged
importance: Undecided → High
Changed in linux (Ubuntu Xenial):
status: New → Invalid
Changed in linux (Ubuntu Bionic):
status: New → Triaged
Changed in linux (Ubuntu Disco):
status: New → Triaged
Changed in linux (Ubuntu Eoan):
status: New → Triaged
importance: Undecided → High
Changed in linux (Ubuntu Disco):
importance: Undecided → High
Changed in linux (Ubuntu Bionic):
importance: Undecided → High
Changed in linux (Ubuntu Xenial):
importance: Undecided → High
Seth Forshee (sforshee) wrote :

Thank you for the report. I've reproduced the issue and have created fixes, which I will attach here.

Changed in linux (Ubuntu):
assignee: nobody → Seth Forshee (sforshee)
importance: High → Undecided
status: Triaged → In Progress
Seth Forshee (sforshee) wrote :
Seth Forshee (sforshee) wrote :
Seth Forshee (sforshee) wrote :
Seth Forshee (sforshee) on 2019-11-05
information type: Private Security → Public Security
tags: added: patch
Seth Forshee (sforshee) on 2019-11-05
description: updated
Niklas Sombert (ytvwld) wrote :

I'm no expert in either kernel or C programming and I didn't test this patch, but it looks good to me.

Also, the resulting code is quite similar to the one Fedora is currently using - they accidentally fixed this bug in https://src.fedoraproject.org/rpms/kernel/c/5df4c5562f191b434edf57e8c92b176baad37cba.
(Debian also seems to be affected: https://salsa.debian.org/kernel-team/linux/blob/4dcfa860/debian/patches/features/all/lockdown/0002-Add-a-SysRq-option-to-lift-kernel-lockdown.patch)

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

This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-eoan' to 'verification-done-eoan'. If the problem still exists, change the tag 'verification-needed-eoan' to 'verification-failed-eoan'.

If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you!

tags: added: verification-needed-eoan

This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-disco' to 'verification-done-disco'. If the problem still exists, change the tag 'verification-needed-disco' to 'verification-failed-disco'.

If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you!

tags: added: verification-needed-disco
tags: added: verification-needed-bionic

This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-bionic' to 'verification-done-bionic'. If the problem still exists, change the tag 'verification-needed-bionic' to 'verification-failed-bionic'.

If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you!

Niklas Sombert (ytvwld) wrote :

I can confirm that this bug is fixed in bionic:

# echo "x" > /proc/sysrq-trigger
Nov 14 20:38:58 panzersperre kernel: sysrq: SysRq :
Nov 14 20:38:58 panzersperre kernel: This sysrq operation is disabled from userspace.

I don't have a disco or eoan to test.

tags: added: verification-done-bionic
removed: verification-needed-bionic
To post a comment you must log in.
This report contains Public Security information  Edit
Everyone can see this security related information.

Other bug subscribers