This bug was fixed in the package grub2 - 2.02~beta2-36ubuntu3.26
---------------
grub2 (2.02~beta2-36ubuntu3.26) xenial; urgency=medium
[ Chris Coulson ]
* SECURITY UPDATE: Heap buffer overflow when encountering commands that
cannot be tokenized to less than 8192 characters.
- 0082-yylex-Make-lexer-fatal-errors-actually-be-fatal.patch: Make
fatal lexer errors actually be fatal
- CVE-2020-10713
* SECURITY UPDATE: Multiple integer overflow bugs that could result in
heap buffer allocations that were too small and subsequent heap buffer
overflows when handling certain filesystems, font files or PNG images.
- 0083-safemath-Add-some-arithmetic-primitives-that-check-f.patch: Add
arithmetic primitives that allow for overflows to be detected
- 0084-calloc-Make-sure-we-always-have-an-overflow-checking.patch:
Make sure that there is always an overflow checking implementation
of calloc() available
- 0085-calloc-Use-calloc-at-most-places.patch: Use calloc where
appropriate
- 0086-malloc-Use-overflow-checking-primitives-where-we-do-.patch: Use
overflow-safe arithmetic primitives when performing allocations
based on the results of operations that might overflow
- 0094-hfsplus-fix-two-more-overflows.patch: Fix integer overflows in
hfsplus
- 0095-lvm-fix-two-more-potential-data-dependent-alloc-over.patch: Fix
more potential integer overflows in lvm
- CVE-2020-14308, CVE-2020-14309, CVE-2020-14310, CVE-2020-14311
* SECURITY UPDATE: Use-after-free when executing a command that causes
a currently executing function to be redefined.
- 0092-script-Remove-unused-fields-from-grub_script_functio.patch:
Remove unused fields from grub_script_function
- 0093-script-Avoid-a-use-after-free-when-redefining-a-func.patch:
Avoid a use-after-free when redefining a function during execution
- CVE-2020-15706
* SECURITY UPDATE: Integer overflows that could result in heap buffer
allocations that were too small and subsequent heap buffer overflows
during initrd loading.
- 0105-linux-Fix-integer-overflows-in-initrd-size-handling.patch: Fix
integer overflows in initrd size handling
- 0106-efilinux-Fix-integer-overflows-in-grub_cmd_initrd.patch: Fix
integer overflows in linuxefi grub_cmd_initrd
- CVE-2020-15707
* Various fixes as a result of code review and static analysis:
- 0087-iso9660-Don-t-leak-memory-on-realloc-failures.patch: Fix a
memory leak on realloc failures when processing symbolic links
- 0088-font-Do-not-load-more-than-one-NAME-section.patch: Fix a
memory leak when processing font files with more than one NAME
section
- 0089-gfxmenu-Fix-double-free-in-load_image.patch: Zero self->bitmap
after it is freed in order to avoid a potential double free later on
- 0090-lzma-Make-sure-we-don-t-dereference-past-array.patch: Fix an
out-of-bounds read in LzmaEncode
- 0091-tftp-Do-not-use-priority-queue.patch: Refactor tftp to not use
priority queues and fix a double free
- 0096-efi-fix-some-malformed-device-path-arithmetic-errors.patch: Fix
various arithmetic errors with malformed device paths
- 0098-Fix-a-regression-caused-by-efi-fix-some-malformed-de.patch: Fix
a NULL deref in the chainloader command introduced by a previous
patch
- 0100-chainloader-Avoid-a-double-free-when-validation-fail.patch:
Avoid a double free in the chainloader command when validation fails
- 0101-relocator-Protect-grub_relocator_alloc_chunk_addr-in.patch:
Protect grub_relocator_alloc_chunk_addr input arguments against
integer overflow / underflow
- 0102-relocator-Protect-grub_relocator_alloc_chunk_align-m.patch:
Protect grub_relocator_alloc_chunk_align max_addr argument against
integer underflow
- 0103-relocator-Fix-grub_relocator_alloc_chunk_align-top-m.patch: Fix
grub_relocator_alloc_chunk_align top memory allocation
- 0104-linux-loader-avoid-overflow-on-initrd-size-calculati.patch:
Avoid overflow on initrd size calculation
* debian/patches/linuxefi_disable_sb_fallback.patch: Disallow unsigned
kernels if UEFI Secure Boot is enabled. If UEFI Secure Boot is enabled
and kernel signature verification fails, do not boot the kernel. Patch
from Linn Crosetto. (LP: #1401532)
* ubuntu-Make-the-linux-command-in-EFI-grub-always-try.patch:
- Make the linux command in EFI grub always try EFI handover
[ Dimitri John Ledkov ]
* SECURITY UPDATE: Grub does not enforce kernel signature validation
when the shim protocol isn't present.
- 0097-linuxefi-fail-kernel-validation-without-shim-protoco.patch:
Fail kernel validation if the shim protocol isn't available
- CVE-2020-15705
-- Chris Coulson <chris.coul...@canonical.com> Mon, 20 Jul 2020
21:28:33 +0100
** Changed in: grub2 (Ubuntu Xenial)
Status: In Progress => Fix Released
** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2020-10713
** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2020-14308
** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2020-14309
** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2020-14310
** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2020-14311
** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2020-15705
** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2020-15706
** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2020-15707
--
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1401532
Title:
GRUB's Secure Boot implementation loads unsigned kernel without
warning
Status in grub2 package in Ubuntu:
Fix Released
Status in grub2-signed package in Ubuntu:
Fix Released
Status in grub2 source package in Trusty:
Fix Released
Status in grub2-signed source package in Trusty:
Fix Released
Status in grub2 source package in Xenial:
Fix Released
Status in grub2-signed source package in Xenial:
In Progress
Status in grub2 source package in Bionic:
Fix Released
Status in grub2-signed source package in Bionic:
Fix Released
Bug description:
[Rationale]
GRUB should help us enforce that in UEFI mode, only signed kernels are
loaded. It should not silently fall back to loading unsigned kernels.
[Impact]
All our users booting in UEFI; on all supported releases.
[Test cases]
= grub2 =
Booting unsigned kernels:
1) Try to boot a custom kernel
2) Verify that the kernel will not be loaded by grub (you should see an error
message about the signature)
Booting signed kernels:
1) Try to boot an official signed kernel (from -release or -updates)
2) Verify that the system boots normally and no warnings are shown about
signature.
[Regression Potential]
Any failure to boot presenting as a failure to load the kernel from within
grub, with an "invalid signature" type error message or not, should be
investigated as a potential regression of this stable update.
---
Me and some other students have conducted some various experiments on
Secure Boot enabled machines. The main focus of the tests was to
circumvent Secure Boot and load unsigned kernels or kernels that have
been signed with other keys.
On your SecureBoot (https://wiki.ubuntu.com/SecurityTeam/SecureBoot)
it is outlined that GRUB will boot unsigned kernels when the kernel is
unsigned. During one of our experiments it seemed that this statement
was true and that GRUB loads unsigned kernels as described on your
page. We understand that for various reasons GRUB should still support
the use-case when an unsigned kernel must be loaded, but with the
current approach the user isn't aware if there is a whole chain of
trust. For example, it could still be possible to load some malware
before it boots the Operating System itself (bootkits). One of the
many reasons that Secure Boot has been developed is to protect the
user from these kind of attacks.
With the current approach the purpose of Secure Boot is somewhat
defeated, and the user doesn't know if the whole chain has been
verified or not. It could easily be the case that an unsigned kernel
has been loaded by Ubuntu without the user noticing. From our point of
view, a better approach would be to inform the user that an unsigned
kernel will be loaded and that the user can make a choice if he/she
wants to proceed. The default action could be to accept the option,
remember the user's option and sometimes remind the user of the fact
that it is loading an unsigned kernel.
This problem is of course related to GRUB itself and not to Ubuntu
itself. The reason for filing this bug and informing the SecurityTeam
of Ubuntu is to ask for their opinions and what your point of view is
on the current approach and to see if other users classify this as a
"bug".
GRUB2 versions: grub-2.02~beta2, 1.34.1+2.02~beta2-9ubuntu1
Ubuntu version: Trusty (will also affect newer and older versions, GRUB
specific problem)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1401532/+subscriptions
_______________________________________________
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help : https://help.launchpad.net/ListHelp
