Ola Lundqvist <o...@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 <b...@debian.org>
