[OpenSSL-1.0.2] CVE-2020-1971 - EDIPARTYNAME NULL pointer de-reference

[Takehiko NOZAKI]

detailed info:
https://www.openssl.org/news/secadv/20201208.txt

fixes:
https://github.com/openssl/openssl/commit/aa0ad2011d3e7ad8a611da274ef7d9c7706e289b
https://github.com/openssl/openssl/commit/f960d81215ebf3f65e03d4d5d857fb9b666d6920
https://github.com/openssl/openssl/commit/1ecc76f6746cefd502c7e9000bdfa4e5d7911386
https://github.com/openssl/openssl/commit/41d62636fd996c031c0c7cef746476278583dc9e

[Takehiko NOZAKI]

BUGFIX: Issue #195 - CVE-2020-1971 EDIPARTYNAME NULL pointer de-reference

cherry-picked from OpenSSL_1_1_1-stable branch with some modification by me: https://github.com/openssl/openssl/commit/aa0ad2011d3e7ad8a611da274ef7d9c7706e289b https://github.com/openssl/openssl/commit/f960d81215ebf3f65e03d4d5d857fb9b666d6920 https://github.com/openssl/openssl/commit/1ecc76f6746cefd502c7e9000bdfa4e5d7911386 https://github.com/openssl/openssl/commit/41d62636fd996c031c0c7cef746476278583dc9e

original commit messages:

DirectoryString is a CHOICE type and therefore uses explicit tagging

EDIPartyName has 2 fields that use a DirectoryString. However they were marked as implicit tagging - which is not correct for a CHOICE type.

Additionally the partyName field was marked as Optional when, according to RFC5280 it is not.

Many thanks to github user @filipnavara for reporting this issue. Also to David Benjamin from Google who independently identified and reported it.

Fixes #6859

Reviewed-by: Tomas Mraz [e-mail]

(cherry-picked from commit aa0ad2011d3e7ad8a611da274ef7d9c7706e289b)

Correctly compare EdiPartyName in GENERAL_NAME_cmp()

If a GENERAL_NAME field contained EdiPartyName data then it was incorrectly being handled as type "other". This could lead to a segmentation fault.

Many thanks to David Benjamin from Google for reporting this issue.

CVE-2020-1971

Reviewed-by: Tomas Mraz [e-mail]

(cherry-picked from commit f960d81215ebf3f65e03d4d5d857fb9b666d6920)

Check that multi-strings/CHOICE types don't use implicit tagging

It never makes sense for multi-string or CHOICE types to use implicit tagging since the content would be ambiguous. It is an error in the template if this ever happens. If we detect it we should stop parsing.

Thanks to David Benjamin from Google for reporting this issue.

Reviewed-by: Tomas Mraz [e-mail]

(cherry-picked from commit 1ecc76f6746cefd502c7e9000bdfa4e5d7911386)

Complain if we are attempting to encode with an invalid ASN.1 template

It never makes sense for multi-string or CHOICE types to have implicit tagging. If we have a template that uses the in this way then we should immediately fail.

Thanks to David Benjamin from Google for reporting this issue.

Reviewed-by: Tomas Mraz [e-mail]

(cherry-picked from commit 41d62636fd996c031c0c7cef746476278583dc9e)

→ <<cset 5c58a29e4969>>