Bug 950804 - (CVE-2015-7837) VUL-0: CVE-2015-7837: kernel: securelevel disabled after kexec
(CVE-2015-7837)
VUL-0: CVE-2015-7837: kernel: securelevel disabled after kexec
Status: RESOLVED FIXED
Classification: Novell Products
Product: SUSE Security Incidents
Classification: Novell Products
Component: Incidents
unspecified
Other Other
: P3 - Medium : Normal
: ---
Assigned To: Joey Lee
Security Team bot
https://smash.suse.de/issue/157873/
CVSSv2:RedHat:CVE-2015-7837:1.9:(AV:L...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2015-10-16 16:04 UTC by Andreas Stieger
Modified: 2018-07-03 20:58 UTC (History)
5 users (show)

See Also:
Found By: Security Response Team
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andreas Stieger 2015-10-16 16:04:42 UTC
A vulnerability was found in kexec, allowing the attacker to bypass the security mechanism of securelevel/secureboot combination.

When the kernel was booted with UEFI Secure Boot enabled, securelevel is set. If kexec (either through crash or admin action) is then used to load the same kernel, after reboot securelevel is disabled. In this state, the system is missing the protections provided by securelevel, for example kexec may be used to load an unsigned kernel via the legacy system call kexec_load. In the securelevel patchset, the state of UEFI Secure Boot is queried in the EFI stub, and sets a boot_params flag to indicate the state of UEFI Secure Boot. This flag is then used in setup_arch() to determine the correct state of securelevel. If the kernel is not booted via the EFI stub, securelevel is not set even if UEFI Secure Boot is enabled.

Patch can be found in product bug:

https://bugzilla.redhat.com/show_bug.cgi?id=1243998#c3 (currently locked)

CVE assignment:

http://seclists.org/oss-sec/2015/q4/85

References:
https://bugzilla.redhat.com/show_bug.cgi?id=1272472
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-7837
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-7837



Possible fix?
https://github.com/mjg59/linux/commit/4980702888a73e0fd4b48ef6f6683345011aa3a6
Comment 2 Swamp Workflow Management 2015-10-16 22:01:36 UTC
bugbot adjusting priority
Comment 5 Joey Lee 2015-10-20 16:22:26 UTC
Yes, the secure_boot flag should also replicate to crash kernel.
Comment 6 Joey Lee 2015-10-20 16:30:29 UTC
(In reply to Joey Lee from comment #5)
> Yes, the secure_boot flag should also replicate to crash kernel.

The kexec_load and kexec_file_load both exist on SLE12-SP1 kernel, and both of them rely on secure_boot flag to enforce verification.

I will backport Dave Young's patch to SLE12-SP1 kernel.
Comment 7 Joey Lee 2015-10-20 16:32:20 UTC
(In reply to Joey Lee from comment #6)
> (In reply to Joey Lee from comment #5)
> > Yes, the secure_boot flag should also replicate to crash kernel.
> 
> The kexec_load and kexec_file_load both exist on SLE12-SP1 kernel, and both
> of them rely on secure_boot flag to enforce verification.
                                      ^^^^^^^^^^^^^^^^^^^^
                              enforce verification (kexec_file_load) or block (kexec_load)
> 
> I will backport Dave Young's patch to SLE12-SP1 kernel.
Comment 8 Joey Lee 2015-10-22 10:11:51 UTC
Backported patch to SLE12-SP1:

commit 3e7194a28c22e3507ff757b0730e4ea02fd4f798
Author: Lee, Chun-Yi <jlee@suse.com>
Date:   Thu Oct 22 15:17:52 2015 +0800

    kexec/uefi: copy secure_boot flag in boot params across kexec
    reboot (bsc#950804).
Comment 9 Joey Lee 2015-10-22 10:14:48 UTC
Set this issue to FIXED.
Comment 10 Marcus Meissner 2015-10-22 11:15:51 UTC
is opensuse affected in any version?
Comment 11 Joey Lee 2015-10-23 05:57:53 UTC
(In reply to Marcus Meissner from comment #10)
> is opensuse affected in any version?

NO, openSUSE kernel didn't lock-down any functions on secure boot environment.
Comment 12 Joey Lee 2015-10-23 05:58:28 UTC
(In reply to Marcus Meissner from comment #10)
> is opensuse affected in any version?

NO, openSUSE kernel didn't lock-down any functions on secure boot environment.