Re: [security-announce] Heads up: "BootHole" security issue

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [security-announce] Heads up: "BootHole" security issue

mailinglisten@posteo.de
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
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [security-announce] Heads up: "BootHole" security issue

Marcus Meissner
On Thu, Jul 30, 2020 at 02:46:35PM +0200, [hidden email] 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
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [security-announce] Heads up: "BootHole" security issue

mailinglisten@posteo.de
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


--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [security-announce] Heads up: "BootHole" security issue

Marcus Meissner
Hi,

On Fri, Jul 31, 2020 at 10:30:47PM +0200, [hidden email] 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
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [security-announce] Heads up: "BootHole" security issue

Lew Wolfgang
On 07/31/2020 11:14 PM, Marcus Meissner wrote:

> On Fri, Jul 31, 2020 at 10:30:47PM +0200, [hidden email] 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-booting-due-to-boothole-patches/

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


--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [security-announce] Heads up: "BootHole" security issue

Marcus Meissner
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, [hidden email] 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-booting-due-to-boothole-patches/

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
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [security-announce] Heads up: "BootHole" security issue

Marcus Meissner
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, [hidden email] 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-booting-due-to-boothole-patches/
>
> 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

opensuse-new-signing-cert-202007.crt (1K) Download Attachment
signature.asc (849 bytes) Download Attachment