tree 04ff3b2029564ba5aef3931b25f74712f4f86578
parent d864b10871cd4370fe574816b489c819c675ccc7
author Filippo Valsorda <filippo@golang.org> 1556047954 -0400
committer Filippo Valsorda <filippo@golang.org> 1556138155 +0000

openpgp/clearsign: reject potentially misleading headers and messages

Aida Mynzhasova of SEC Consult Vulnerability Lab reported that the
clearsign package accepts some malformed messages, which can make it
possible for an attacker to trick a human user (but not a Go program)
into thinking unverified text is part of the message.

For example, if in the following message the vertical tab character is
printed as a new line, a human observer could believe that the
unverified header text is part of the signed message.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1\x0b\x0bThis text is part of the header.

Hello world!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iJwEAQECAAYFAk8kMuEACgkQO9o98PRieSpMsAQAhmY/vwmNpflrPgmfWsYhk5O8
[...]
MyTpno24AjIAGb+mH1U=
=hIJ6
-----END PGP SIGNATURE-----

The OpenPGP specs are delightfully vague about purpose and validation of
these headers. RFC 4880, Section 7 says

    The cleartext signed message consists of:

        - The cleartext header '-----BEGIN PGP SIGNED MESSAGE-----' on a
        single line,

        - One or more "Hash" Armor Headers,

        - Exactly one empty line not included into the message digest,
        [...]

but also

    If MD5 is the only hash used, then an
    implementation MAY omit this header for improved V2.x compatibility.

and

    If more than one message digest is used in the signature, the "Hash"
    armor header contains a comma-delimited list of used message digests.

which seems to suggest that there can be zero or more Hash headers, each
with one or more algorithms, and no other header types.

Anyway, it's entirely unclear what security purpose, if any, the Hash
header accomplishes. If the hash is too weak to be secure or
unsupported, the verification will fail. Otherwise, the user shouldn't
care. Given its dubious function, avoid breaking abstractions to check
that it matches the signature, and just document it as unverified.

As for valid characters, RFC 4880 is silent, except reluctantly
mentioning that the Comment header can be UTF-8, but I am going to
assume that all hash algorithms will have ASCII names, because come on.

Even more importantly, reject non-Hash SIGNED MESSAGE headers (as opposed
to the SIGNATURE headers), to prevent a "Thank you!" message turning into

-----BEGIN PGP SIGNED MESSAGE-----
Reminder: I need you to wire $100k to 12345566 as soon as possible.

Thank you!
-----BEGIN PGP SIGNATURE-----
[...]

While at it, also check for trailing characters after the signed message
delimiter, as they are invalid and can be similarly used to confuse humans.

The Decode API is also unfortunate in that it doesn't return an error,
so we can't tell the user what's wrong with the message, but that's what
we've got.

Change-Id: I8a72c4851075337443d7a27e0b49a6b6e39f5a41
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/453011
Reviewed-by: Adam Langley <agl@google.com>
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/173778
Run-TryBot: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>