Re: golang-go.crypto / CVE-2019-11841
I agree with you about the hash part (the main part of it) of this CVE. In fact this CVE is about two different things. If gnupg do hash validation I think go should do the same.
I was referring to the second part of the vulnerability described in "Moreover, since...". Now when I read about it, it is clear that it is only referring to the PHP header part and not the rest of the text. I wonder if that should be seen as a separate vulnerability, that people think the whole text is signed, while it is just a part of it... But that should probably be on the application layer on top of this library.
Ola Lundqvist <firstname.lastname@example.org> writes:
> To completely fix the second part of this CVE I think an API change is
> The API need to return a list of unsigned and signed portions of the
> message so the application using it can make it visible what parts are
> signed and what parts are not.
> However such a change is large and cannot be done in LTS.
I think you might have misunderstood the issue. Thee problem isn't
signed vs unsigned parts of a message. The problem is that the Hash
header can be altered in transit. gnupg will fail the signature
verification if this happens, but golang-go.crypto will not.
--- cut ---
$ gpg hash_spoof.asc
gpg: WARNING: no command supplied. Trying to guess what you mean ...
gpg: Signature made Fr 29 Mär 2019 13:00:03 CET
using RSA key 0175949FAEB97005E02272D95D5B3AD9D04EFAEE
gpg: WARNING: signature digest conflict in message
gpg: Can't check signature: General error
--- cut ---
I am not sure I understand why upstream is resistant to fixing it
actually. All you need to do is get the actual hash used to sign the
message, compare it with the Hash header, and reject the message if they
> Regarding the security purpose of the hash information I cannot really
> judge. I think it serves very little function but I could be wrong.
It is not just that the hash header can contain an incorrect hash that
is the problem. The hash header could also be changed - with the message
in transit - to contain a hidden message - which can appear to be
authenticate because it is within the signed part of the message.
For example, the following message will pass the golang-go.crypto test
(but as above fail the gnupg test).
-----BEGIN PGP SIGNED MESSAGE-----
Hash: I need you to wire $100k to 12345566 as soon as possible.
Message to be signed
-----BEGIN PGP SIGNATURE-----
-----END PGP SIGNATURE-----
If the hash header was not important, then there would be no need to
even include it in the message in the first place. But the fact it is
included, and it could confuse programs and/or humans if it is altered.
So the value of this header should be validated.
Brian May <email@example.com>
--- Inguza Technology AB --- MSc in Information Technology ----