2019-11-05 14:12:34 |
Niklas Sombert |
bug |
|
|
added bug |
2019-11-05 15:05:33 |
Tyler Hicks |
bug |
|
|
added subscriber Canonical Kernel Security Team |
2019-11-05 15:47:16 |
Tyler Hicks |
linux (Ubuntu): status |
New |
Triaged |
|
2019-11-05 15:47:18 |
Tyler Hicks |
linux (Ubuntu): importance |
Undecided |
High |
|
2019-11-05 15:47:35 |
Tyler Hicks |
nominated for series |
|
Ubuntu Bionic |
|
2019-11-05 15:47:35 |
Tyler Hicks |
bug task added |
|
linux (Ubuntu Bionic) |
|
2019-11-05 15:47:35 |
Tyler Hicks |
nominated for series |
|
Ubuntu Eoan |
|
2019-11-05 15:47:35 |
Tyler Hicks |
bug task added |
|
linux (Ubuntu Eoan) |
|
2019-11-05 15:47:35 |
Tyler Hicks |
nominated for series |
|
Ubuntu Focal |
|
2019-11-05 15:47:35 |
Tyler Hicks |
bug task added |
|
linux (Ubuntu Focal) |
|
2019-11-05 15:47:35 |
Tyler Hicks |
nominated for series |
|
Ubuntu Xenial |
|
2019-11-05 15:47:35 |
Tyler Hicks |
bug task added |
|
linux (Ubuntu Xenial) |
|
2019-11-05 15:47:35 |
Tyler Hicks |
nominated for series |
|
Ubuntu Disco |
|
2019-11-05 15:47:35 |
Tyler Hicks |
bug task added |
|
linux (Ubuntu Disco) |
|
2019-11-05 15:47:43 |
Tyler Hicks |
linux (Ubuntu Xenial): status |
New |
Invalid |
|
2019-11-05 15:47:48 |
Tyler Hicks |
linux (Ubuntu Bionic): status |
New |
Triaged |
|
2019-11-05 15:47:50 |
Tyler Hicks |
linux (Ubuntu Disco): status |
New |
Triaged |
|
2019-11-05 15:47:53 |
Tyler Hicks |
linux (Ubuntu Eoan): status |
New |
Triaged |
|
2019-11-05 15:48:01 |
Tyler Hicks |
linux (Ubuntu Eoan): importance |
Undecided |
High |
|
2019-11-05 15:48:03 |
Tyler Hicks |
linux (Ubuntu Disco): importance |
Undecided |
High |
|
2019-11-05 15:48:04 |
Tyler Hicks |
linux (Ubuntu Bionic): importance |
Undecided |
High |
|
2019-11-05 15:48:05 |
Tyler Hicks |
linux (Ubuntu Xenial): importance |
Undecided |
High |
|
2019-11-05 16:05:12 |
Terry Rudd |
bug |
|
|
added subscriber Terry Rudd |
2019-11-05 19:58:28 |
Seth Forshee |
linux (Ubuntu): importance |
High |
Undecided |
|
2019-11-05 19:58:28 |
Seth Forshee |
linux (Ubuntu): status |
Triaged |
In Progress |
|
2019-11-05 19:58:28 |
Seth Forshee |
linux (Ubuntu): assignee |
|
Seth Forshee (sforshee) |
|
2019-11-05 19:59:35 |
Seth Forshee |
attachment added |
|
Patch for bionic https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1851380/+attachment/5303105/+files/0001-UBUNTU-SAUCE-efi-lockdown-Really-don-t-allow-lifting.patch |
|
2019-11-05 20:00:10 |
Seth Forshee |
attachment added |
|
Patch for disco https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1851380/+attachment/5303108/+files/0001-UBUNTU-SAUCE-efi-lockdown-Really-don-t-allow-lifting.patch |
|
2019-11-05 20:00:43 |
Seth Forshee |
attachment added |
|
Patch for eoan/focal https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1851380/+attachment/5303109/+files/0001-UBUNTU-SAUCE-efi-lockdown-Really-don-t-allow-lifting.patch |
|
2019-11-05 20:01:31 |
Seth Forshee |
bug |
|
|
added subscriber Seth Forshee |
2019-11-05 20:15:50 |
Seth Forshee |
information type |
Private Security |
Public Security |
|
2019-11-05 20:25:54 |
Ubuntu Foundations Team Bug Bot |
tags |
amd64 apport-bug bionic package-from-proposed |
amd64 apport-bug bionic package-from-proposed patch |
|
2019-11-05 20:27:37 |
Seth Forshee |
description |
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 |
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 |
|
2019-11-07 01:06:21 |
Khaled El Mously |
linux (Ubuntu Bionic): status |
Triaged |
Fix Committed |
|
2019-11-07 01:06:23 |
Khaled El Mously |
linux (Ubuntu Disco): status |
Triaged |
Fix Committed |
|
2019-11-07 01:06:25 |
Khaled El Mously |
linux (Ubuntu Eoan): status |
Triaged |
Fix Committed |
|
2019-11-14 18:31:21 |
Ubuntu Kernel Bot |
tags |
amd64 apport-bug bionic package-from-proposed patch |
amd64 apport-bug bionic package-from-proposed patch verification-needed-eoan |
|
2019-11-14 18:46:27 |
Ubuntu Kernel Bot |
tags |
amd64 apport-bug bionic package-from-proposed patch verification-needed-eoan |
amd64 apport-bug bionic package-from-proposed patch verification-needed-disco verification-needed-eoan |
|
2019-11-14 18:48:22 |
Ubuntu Kernel Bot |
tags |
amd64 apport-bug bionic package-from-proposed patch verification-needed-disco verification-needed-eoan |
amd64 apport-bug bionic package-from-proposed patch verification-needed-bionic verification-needed-disco verification-needed-eoan |
|
2019-11-14 19:42:17 |
Niklas Sombert |
tags |
amd64 apport-bug bionic package-from-proposed patch verification-needed-bionic verification-needed-disco verification-needed-eoan |
amd64 apport-bug bionic package-from-proposed patch verification-done-bionic verification-needed-disco verification-needed-eoan |
|
2019-12-02 12:43:50 |
Launchpad Janitor |
linux (Ubuntu Disco): status |
Fix Committed |
Fix Released |
|
2019-12-02 12:43:50 |
Launchpad Janitor |
cve linked |
|
2019-15794 |
|
2019-12-02 12:51:47 |
Launchpad Janitor |
linux (Ubuntu Eoan): status |
Fix Committed |
Fix Released |
|
2019-12-02 13:04:55 |
Launchpad Janitor |
linux (Ubuntu Bionic): status |
Fix Committed |
Fix Released |
|
2019-12-06 15:57:44 |
Launchpad Janitor |
linux (Ubuntu Focal): status |
In Progress |
Fix Released |
|
2019-12-17 23:19:36 |
Guillaume Michaud |
bug watch added |
|
https://github.com/hirschmann/nbfc/issues/414 |
|
2019-12-17 23:19:36 |
Guillaume Michaud |
bug watch added |
|
https://github.com/hirschmann/nbfc/issues/472 |
|