Am 29.07.20 um 20:07 schrieb Marcus Meissner:
Hi folks,
Researchers from Eclypsium just published a new vulnerability in grub2 called "BootHole".
We put a highlevel view in a blog: https://www.suse.com/c/suse-addresses-grub2-secure-boot-issue/
and our TID: https://www.suse.com/support/kb/doc/?id=000019673
Unfortunately, neither document gives the complete key id so we can know what SUSE keys precisely are to be changed.
If I understand correctly
"openSUSE Secure Boot CA" with sha1 fingerprint 46:59:83:8c:82:03:fe:15:52:ad:19:e1:86:09:db:21:7e:3a:d2:4f
will stay unchanged?
Is the new key available for download somewhere? I have my own set of PK/KEK and import such keys usually manually.
Thanks
On Thu, Jul 30, 2020 at 02:46:35PM +0200, mailinglisten@posteo.de wrote:
Am 29.07.20 um 20:07 schrieb Marcus Meissner:
Hi folks,
Researchers from Eclypsium just published a new vulnerability in grub2 called "BootHole".
We put a highlevel view in a blog: https://www.suse.com/c/suse-addresses-grub2-secure-boot-issue/
and our TID: https://www.suse.com/support/kb/doc/?id=000019673
Unfortunately, neither document gives the complete key id so we can know what SUSE keys precisely are to be changed.
If I understand correctly
"openSUSE Secure Boot CA" with sha1 fingerprint 46:59:83:8c:82:03:fe:15:52:ad:19:e1:86:09:db:21:7e:3a:d2:4f
will stay unchanged?
Yes, the openSUSE Secure Boot CA will stay unchanged.
Is the new key available for download somewhere? I have my own set of PK/KEK and import such keys usually manually.
We still need to generate the new key, we need to wait until the fixed grub2 has been checked into openSUSE:Factory first to avoid having it signed by the new key.
I will send it as reply as soon as its available.
Ciao, Marcus
Am 30.07.20 um 15:10 schrieb Marcus Meissner:
(......) will stay unchanged?
Yes, the openSUSE Secure Boot CA will stay unchanged.
Is the new key available for download somewhere? I have my own set of PK/KEK and import such keys usually manually.
We still need to generate the new key, we need to wait until the fixed grub2 has been checked into openSUSE:Factory first to avoid having it signed by the new key.
I will send it as reply as soon as its available.
Out of curiousity, what toolchain do you use to create/handle secure boot keys?
sbsigntools and efitools have never been part of any official SUSE repo. Lucky, the author of these tools has his own repo.
My dear, you use M$ Windoze to handle secure boot keys, right?
best regards
Hi,
On Fri, Jul 31, 2020 at 10:30:47PM +0200, mailinglisten@posteo.de wrote:
Am 30.07.20 um 15:10 schrieb Marcus Meissner:
(......) will stay unchanged?
Yes, the openSUSE Secure Boot CA will stay unchanged.
Is the new key available for download somewhere? I have my own set of PK/KEK and import such keys usually manually.
We still need to generate the new key, we need to wait until the fixed grub2 has been checked into openSUSE:Factory first to avoid having it signed by the new key.
I will send it as reply as soon as its available.
Out of curiousity, what toolchain do you use to create/handle secure boot keys?
The signing itself is done by the open build service in the background.
sbsigntools and efitools have never been part of any official SUSE repo. Lucky, the author of these tools has his own repo.
We use the "pesign" toolset, from here https://github.com/rhboot/pesign
My dear, you use M$ Windoze to handle secure boot keys, right?
No, and your tone is uncalled for.
Ciao, Marcus
On 07/31/2020 11:14 PM, Marcus Meissner wrote:
On Fri, Jul 31, 2020 at 10:30:47PM +0200, mailinglisten@posteo.de wrote:
Am 30.07.20 um 15:10 schrieb Marcus Meissner:
(......) will stay unchanged?
Yes, the openSUSE Secure Boot CA will stay unchanged.
Is the new key available for download somewhere? I have my own set of PK/KEK and import such keys usually manually.
We still need to generate the new key, we need to wait until the fixed grub2 has been checked into openSUSE:Factory first to avoid having it signed by the new key.
I will send it as reply as soon as its available.
Out of curiousity, what toolchain do you use to create/handle secure boot keys?
The signing itself is done by the open build service in the background.
sbsigntools and efitools have never been part of any official SUSE repo. Lucky, the author of these tools has his own repo.
We use the "pesign" toolset, from here https://github.com/rhboot/pesign
Ars Technica is reporting boot failures after the BootHole patch is installed on Red Hat, CentOS, Ubuntu, Debian and maybe others.
https://arstechnica.com/gadgets/2020/07/red-hat-and-centos-systems-arent-boo...
Did the openSUSE patch get delayed because of the key id issue mentioned here:
https://lists.opensuse.org/opensuse-security/2020-07/msg00001.html
Regards, Lew
On Sat, Aug 01, 2020 at 01:50:56PM -0700, Lew Wolfgang wrote:
On 07/31/2020 11:14 PM, Marcus Meissner wrote:
On Fri, Jul 31, 2020 at 10:30:47PM +0200, mailinglisten@posteo.de wrote:
Am 30.07.20 um 15:10 schrieb Marcus Meissner:
(......) will stay unchanged?
Yes, the openSUSE Secure Boot CA will stay unchanged.
Is the new key available for download somewhere? I have my own set of PK/KEK and import such keys usually manually.
We still need to generate the new key, we need to wait until the fixed grub2 has been checked into openSUSE:Factory first to avoid having it signed by the new key.
I will send it as reply as soon as its available.
Out of curiousity, what toolchain do you use to create/handle secure boot keys?
The signing itself is done by the open build service in the background.
sbsigntools and efitools have never been part of any official SUSE repo. Lucky, the author of these tools has his own repo.
We use the "pesign" toolset, from here https://github.com/rhboot/pesign
Ars Technica is reporting boot failures after the BootHole patch is installed on Red Hat, CentOS, Ubuntu, Debian and maybe others.
https://arstechnica.com/gadgets/2020/07/red-hat-and-centos-systems-arent-boo...
As far as I understand they backported a buggy optional patch.
We only backported mandatory patches from the patchset.
Did the openSUSE patch get delayed because of the key id issue mentioned here:
https://lists.opensuse.org/opensuse-security/2020-07/msg00001.html
Yes.
We need to make sure that the buggy insecure old grub2 is not built with the new key.
As the fixed grub2 package is now checked into factory, we will create a new signing key, and then start delivering updates, both Tumbleweed and also for Leap.
Ciao, Marcus
On Sun, Aug 02, 2020 at 08:30:26AM +0200, Marcus Meissner wrote:
On Sat, Aug 01, 2020 at 01:50:56PM -0700, Lew Wolfgang wrote:
On 07/31/2020 11:14 PM, Marcus Meissner wrote:
On Fri, Jul 31, 2020 at 10:30:47PM +0200, mailinglisten@posteo.de wrote:
Am 30.07.20 um 15:10 schrieb Marcus Meissner:
(......) will stay unchanged?
Yes, the openSUSE Secure Boot CA will stay unchanged.
Is the new key available for download somewhere? I have my own set of PK/KEK and import such keys usually manually.
We still need to generate the new key, we need to wait until the fixed grub2 has been checked into openSUSE:Factory first to avoid having it signed by the new key.
I will send it as reply as soon as its available.
Out of curiousity, what toolchain do you use to create/handle secure boot keys?
The signing itself is done by the open build service in the background.
sbsigntools and efitools have never been part of any official SUSE repo. Lucky, the author of these tools has his own repo.
We use the "pesign" toolset, from here https://github.com/rhboot/pesign
Ars Technica is reporting boot failures after the BootHole patch is installed on Red Hat, CentOS, Ubuntu, Debian and maybe others.
https://arstechnica.com/gadgets/2020/07/red-hat-and-centos-systems-arent-boo...
As far as I understand they backported a buggy optional patch.
We only backported mandatory patches from the patchset.
Did the openSUSE patch get delayed because of the key id issue mentioned here:
https://lists.opensuse.org/opensuse-security/2020-07/msg00001.html
Yes.
We need to make sure that the buggy insecure old grub2 is not built with the new key.
As the fixed grub2 package is now checked into factory, we will create a new signing key, and then start delivering updates, both Tumbleweed and also for Leap.
Update:
The openSUSE signing key was rotated today.
- tumbleweed is already rebuilding all secure boot relevant packages for their next snapshot.
- leap maintenance we pushed grub2 to QA, also 15.1 kernel. ... More packages will follow in the next days.
The replacement of shim will only happen after we fixed everything. (Tumbleweed earlier than Leap ;)
Ciao, Marcus
-
Lew Wolfgang -
mailinglisten＠posteo.de -
Marcus Meissner