Hi Brian 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. Cheers // Ola On Tue, 8 Sep 2020 at 00:16, Brian May <b...@debian.org> wrote: > 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> > -- --- Inguza Technology AB --- MSc in Information Technology ---- | o...@inguza.com o...@debian.org | | http://inguza.com/ Mobile: +46 (0)70-332 1551 | ---------------------------------------------------------------
