Re: golang-go.crypto / CVE-2019-11841
Ola Lundqvist <ola@inguza.com> writes:
> To completely fix the second part of this CVE I think an API change is
> necessary.
> 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
gpg:
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
are different.
> 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-----
iQEzBAEBAgAdFiEEAXWUn665cAXgInLZXVs62dBO+u4FAlyeCMMACgkQXVs62dBO
+u6WeQgAvOTZAkwtXCZ2woIbHk+g3fgOiCOF8YtXgZCyDYZgR/JIf1+iCh7lWAjq
9/JcnifNB9lX6hyxy4qoT8loLAHNeoUzSkKiliRMcQFhtfCPInRCRtAnKDfkiA5N
0C9CesJYXoASBRafUgxeI7Q29tVdPNC8WVjJtA72yafu4b63TXKdCcu+TCHtH5lV
l0rqS1JET/+UGycO+gbvegsAoNhmQp8qkFnJTTS6kJgmCs9TJlAmeX1wT8V5f5L+
7pRe45ZBmlA7oi4lylvIp+WG1KJVgrPzeQOkybF2rFRuMxjlvqfO1/4lLrtXgA/7
v8H3ZsqUV9T/HNx5bFPOQJjbOhBVRg==
=Bb6N
-----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 <bam@debian.org>
Reply to: