Bug 1411213 (expired-secure-boot-certs)

Summary:	pesign-bundled Red Hat Test Certificate and CA expired in 2013
Product:	[Fedora] Fedora	Reporter:	David Ward <david.ward>
Component:	pesign	Assignee:	Peter Jones <pjones>
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	rawhide	CC:	pjones
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2018-01-09 18:53:26 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description David Ward 2017-01-09 06:35:34 UTC

The test certificate and CA that are packaged and installed into an NSS database at /etc/pki/pesign-rh-test are expired. These certificates originate from an additional source file (certs.tar.xz) which is used when building the pesign package for Fedora.

Note that as a result, these expired certificates are currently being used when building unofficial kernel packages, including the Fedora kernel stabilization branch: https://copr.fedorainfracloud.org/coprs/jforbes/kernel-stabilization/


$ certutil -L -d /etc/pki/pesign-rh-test

Certificate Nickname                                         Trust Attributes
                                                             SSL,S/MIME,JAR/XPI

Red Hat Test CA                                              CT,C,C
Red Hat Test Certificate                                     u,u,u
$ certutil -L -d /etc/pki/pesign-rh-test -n "Red Hat Test CA"
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            00:f7:18:65:cc:12:02:b7:d3
        Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption
        Issuer: "CN=Red Hat Test Certifying CA,O="Red Hat, Inc.",L=Cambridge,
            ST=Massachusetts,C=US"
        Validity:
            Not Before: Mon Jul 09 19:12:43 2012
            Not After : Tue Jul 09 19:12:43 2013
        Subject: "CN=Red Hat Test Certifying CA,O="Red Hat, Inc.",L=Cambridge
            ,ST=Massachusetts,C=US"
[...]
$ certutil -L -d /etc/pki/pesign-rh-test -n "Red Hat Test Certificate"
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            00:f7:d9:05:dc:fd:96:96:21
        Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption
        Issuer: "CN=Red Hat Test Certifying CA,O="Red Hat, Inc.",L=Cambridge,
            ST=Massachusetts,C=US"
        Validity:
            Not Before: Mon Jul 09 19:12:44 2012
            Not After : Tue Jul 09 19:12:44 2013
        Subject: "CN=Red Hat Test Certificate,O="Red Hat, Inc.",L=Cambridge,S
            T=Massachusetts,C=US"
[...]

Comment 1 Fedora End Of Life 2017-02-28 10:54:29 UTC

This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle.
Changing version to '26'.

Comment 2 David Ward 2017-05-08 04:36:26 UTC

The expired certificates have not been replaced in 'rawhide' (or Fedora 26).
Changing version back to 'rawhide'.

Comment 3 Jan Kurik 2017-08-15 08:16:53 UTC

This bug appears to have been reported against 'rawhide' during the Fedora 27 development cycle.
Changing version to '27'.

Comment 4 David Ward 2017-12-21 04:15:39 UTC

The expired certificates have not been replaced in 'rawhide' (or Fedora 27).
Changing version back to 'rawhide'.

Comment 5 Peter Jones 2018-01-09 18:53:26 UTC

It doesn't make any difference that the certificate has expired - nothing in the Secure Boot verification chain can safely use the validation window like HTTPS does.  It's just a vestigial artifact of using CMS-like signing.

There's two big problems with using the validation window in this for something like SB:

One issue is that we don't have a trustworthy clock anyway.  If you're trying to do an attack against Secure Boot, you're basically trying to get persistence once you've already got root - either you're trying to install a "bootkit" or you're trying to use a vulnerable OS /as/ a "bootkit".  So an attacker has all the privilege they need to just change the system clock anyway.  

The other issue is that honoring the validation window means /hardware components expire/.  SB's verification is how option ROMs on PCI peripherals are verified, and they need to keep working after the certificate expires.  If anything honors the validation window, that means one day you reboot your machine and your HBAs and video cards simply do not work - your machine looks like it just bricked itself during a reboot.

So in a lot of ways having an expired certificate as the "test" cert is actually the best possible option, because it means we can find anything that's erroneously checking the window.