search

gocsaf / csaf

Tools to download or provide CSAF (Common Security Advisory Framework) documents.
https://csaf.io
40 stars 23 forks source link

Redhat's file signatures fail to verify (because they use OpenPGP signatures with the old signature package V3) #358

Open bernhardreiter opened 1 year ago

bernhardreiter commented 1 year ago

Using csaf_distribution-v2.1.0-gnulinux-amd64: when downloading from redhat.com the signatures do not verify.

curl -L -O https://github.com/csaf-poc/csaf_distribution/releases/download/v2.1.0-gnulinux-amd64.tar.gz
tar -xvmlzf csaf_distribution-v2.1.0-gnulinux-amd64.tar.gz
./csaf_distribution-v2.1.0-gnulinux-amd64/bin-linux-amd64/csaf_downloader --verbose --rate=10 redhat.com
[..]
2023/04/26 09:49:05 [GET]: https://access.redhat.com/security/data/csaf/v2/advisories/2001/rhsa-2001_058.json
[..]
2023/04/26 09:49:06 [GET]: https://access.redhat.com/security/data/csaf/v2/advisories/2001/rhsa-2001_058.json.asc
2023/04/26 09:49:06 Cannot verify signature for https://access.redhat.com/security/data/csaf/v2/advisories/2001/rhsa-2001_058.json
[..]
2023/04/26 09:55:32 Cannot verify signature for https://access.redhat.com/security/data/csaf/v2/advisories/2005/rhsa-2005_586.json
2023/04/26 09:55:32 [GET]: https://access.redhat.com/security/data/csaf/v2/advisories/2005/rhsa-2005_587.json
[..]

Manual checking shows that GnuPG believes in the signature, e.g.:

curl -O https://access.redhat.com/security/data/csaf/v2/advisories/2005/rhsa-2005_586.json
curl -O https://access.redhat.com/security/data/csaf/v2/advisories/2005/rhsa-2005_586.json.asc
gpg --keyserver keyserver2.gnupg.org --recv-keys "77E7 9ABE 9367 3533 ED09  EBE2 DCE3 8235 97F5 EAC4"

gpg -v --verify  rhsa-2005_586.json.asc
gpg: armor header: Version: GnuPG v1
gpg: assuming signed data in 'rhsa-2005_586.json'
gpg: Signature made Do 09 Mär 2023 20:57:15 CET
gpg:                using RSA key DCE3823597F5EAC4
gpg: using pgp trust model
gpg: Good signature from "Red Hat, Inc. (Product Security) <secalert@redhat.com>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: 77E7 9ABE 9367 3533 ED09  EBE2 DCE3 8235 97F5 EAC4
gpg: binary signature, digest algorithm SHA256, key algorithm rsa4096
bernhardreiter commented 1 year ago

@tschmidtb51 we shall investigate, I assume.

@bernhard-herzog can you add your code, to getare more verbose error message from the failed signature

s-l-teichmann commented 1 year ago

I checked out main and upgraded the 3rdparty libs with go get -u -v ./... and rebuilt the checker and it works.

bernhard-herzog commented 1 year ago

Further digging with a debugger reveals that the signature check fails because the signature (I used rhsa-2001_058.json.asc) uses signature packet format version 3 which is not supported by go-crypto.

The code there even produces an error with that information, but detail is then lost in the openpgp library where a more generic "Invalid signature" is returned instead. The CSAF code also suppresses information because any failure during the signature check is turned into a simple boolean and is the reported as "Cannot verify signature ...", so details on why the check failed are lost.

bernhard-herzog commented 1 year ago

I checked out main and upgraded the 3rdparty libs with go get -u -v ./... and rebuilt the checker and it works.

It still doesn't work for me. The code in question that rejects packet version 3 hasn't changed, so I don't think it could work for the signatures I observed the problem with. All of those are in the 2001 subdirectory, I haven't checked any others.

s-l-teichmann commented 1 year ago

I checked out main and upgraded the 3rdparty libs with go get -u -v ./... and rebuilt the checker and it works.

Argh! I used the checker and not the downloader. I can confirm that updating the libs does not help.

bernhardreiter commented 1 year ago

@s-l-teichmann does signature validation work with the checker, though? ;)

bernhardreiter commented 1 year ago

Seems to be https://github.com/ProtonMail/go-crypto/issues/164 which is biting a few people already.

gpg -vv --verify  rhsa-2005_586.json.ascgpg: armor: BEGIN PGP SIGNATURE
gpg: armor header: Version: GnuPG v1
# off=0 ctb=89 tag=2 hlen=3 plen=533
:signature packet: algo 1, keyid DCE3823597F5EAC4
        version 3, created 1678391835, md5len 5, sigclass 0x00
        digest algo 8, begin of digest 5a d6
        data: [4095 bits]
gpg: assuming signed data in 'rhsa-2005_586.json'
gpg: Signature made Do 09 Mär 2023 20:57:15 CET
gpg:                using RSA key DCE3823597F5EAC4
[..]
bernhardreiter commented 1 year ago

Note that https://www.rfc-editor.org/rfc/rfc4880#section-5.2 reads

Implementations SHOULD accept V3 signatures. Implementations SHOULD generate V4 signatures.

(Note that Implementation in the quote refers to implementing OpenPGP itself, not our implementation of the downloader.)

The SHOULD means that Redhat would need to have valid reasons in particular circumstances to create v3 signatures here. Given that their signature has Version: GnuPG v1, they probably should not have created it in 2023. Unless there are special circumstances I'd say that CSAF should mandate at least V4 signatures, because CSAF is a new application and can thus set a modern requirement here.

bernhardreiter commented 1 year ago

@bernhard-herzog can you put in better diagnostic reporting and then assign it to @tschmidtb51 ?

s-l-teichmann commented 1 year ago

@bernhardreiter

>

@s-l-teichmann does signature validation work with the checker, though? ;)

Obviously not. But the failure is noted in the report and not on STDERR where i had looked for the message.

tschmidtb51 commented 1 year ago

@tschmidtb51 we shall investigate, I assume.

Yes. Go ahead.

s-l-teichmann commented 1 year ago

PR #363 added a flag ignoresigcheck to ignore the results of the signature checks in the downloader. Without this the downloads would fail entirely.

andrewgdotcom commented 1 year ago

There is a soft fork of go-crypto at https://github.com/pgpkeys-eu/go-crypto that restores V3 support.

Add the following to go.mod to try it out:

replace github.com/ProtonMail/go-crypto => github.com/pgpkeys-eu/go-crypto v0.0.0-20230506215654-16de0cc09494

bernhardreiter commented 1 year ago

@andrewgdotcom thanks for the hint.

(We are not sure yet, if it wouldn't be better to mandate v4 or higher signatures in the CSAF standard directly. At least V4 SHOULD already be used unless we know the reasoning of Redhat.)

andrewgdotcom commented 1 year ago

RedHat didn't have any reasoning, they just forgot about it:

https://bugzilla.rpmfusion.org/show_bug.cgi?id=6496

bernhardreiter commented 1 year ago

RedHat didn't have any reasoning, they just forgot about it: https://bugzilla.rpmfusion.org/show_bug.cgi?id=6496

That is packaging, I mean fresh CSAF publications (see beginning of this issue). :)

bernhardreiter commented 1 year ago

I've just send an email to Redhat, asking if they could change the signature. Got the contact address from https://www.redhat.com/en/blog/csaf-vex-documents-now-generally-available , the CSAF providermetadata file and https://access.redhat.com/security/team/contact/ .

bernhardreiter commented 1 year ago

There is a new issue https://issues.redhat.com/browse/SECDATA-300 which will lead to new signatures on the files. However, so far it does not say something about the signature packet format, which is the problem here.

We shall stop working on the issue, until we see what Redhat does here.

(We have ignoresigcheck and a better diagnostic message in place already, if I remember correctly.)

bernhardreiter commented 1 year ago

There is a new issue https://issues.redhat.com/browse/SECDATA-300 which will lead to new signatures on the files. However, so far it does not say something about the signature packet format, which is the problem here.

I'll asked Redhat about it.

bernhardreiter commented 1 year ago

Redhat has responded and gave me a new issue, they will address: https://issues.redhat.com/browse/SECDATA-304

bernhardreiter commented 1 year ago

Redhat has made some improvements, so there are now files which have an OpenPGP signature format version 4, which is fine. However not all files have been resigned yet.

A file that works: https://access.redhat.com/security/data/csaf/v2/advisories/2001/rhsa-2001_164.json

Some that do not:

https://access.redhat.com/security/data/csaf/v2/advisories/2002/rhsa-2002_251.json

https://access.redhat.com/security/data/csaf/v2/advisories/2002/rhsa-2002_259.json

https://access.redhat.com/security/data/csaf/v2/advisories/2002/rhsa-2002_270.json https://access.redhat.com/security/data/csaf/v2/advisories/2002/rhsa-2002_271.json https://access.redhat.com/security/data/csaf/v2/advisories/2002/rhsa-2002_287.json https://access.redhat.com/security/data/csaf/v2/advisories/2002/rhsa-2002_288.json https://access.redhat.com/security/data/csaf/v2/advisories/2002/rhsa-2002_289.json https://access.redhat.com/security/data/csaf/v2/advisories/2002/rhsa-2002_290.json

bernhardreiter commented 1 year ago

https://issues.redhat.com/browse/SECDATA-304 has been closed, but

curl -O https://access.redhat.com/security/data/csaf/v2/advisories/2002/rhsa-2002_290.json
curl -O https://access.redhat.com/security/data/csaf/v2/advisories/2002/rhsa-2002_290.json.asc
gpg -vv --verify rhsa-2002_290.json.asc 
:signature packet: algo 1, keyid DCE3823597F5EAC4
        version 3, created 1675238242, md5len 5, sigclass 0x00
        digest algo 8, begin of digest 40 b6
        data: [4093 bits]
gpg: assuming signed data in 'rhsa-2002_290.json'
gpg: Signature made Mi 01 Feb 2023 08:57:22 CET
gpg:                using RSA key DCE3823597F5EAC4

So it is still broken (which can be seen from the version 3 and the time (before June 2023).