QID 980503

Security update has been released for jsrsasign to fix the vulnerability.

Note: The preceding description block is extracted directly from the security advisory. Using automation, we have attempted to clean and format it as much as possible without introducing additional issues.

Jsrsasign supports ECDSA signature validation which signature value is represented by ASN.1 DER encoding. This vulnerablity may accept a wrong ASN.1 DER encoded ECDSA signature such as:

- wrong multi-byte ASN.1 length of TLV (ex. 0x820045 even though 0x45 is correct)
- prepending zeros with ASN.1 INTEGER value (ex. 0x00000123 even though 0x0123 is correct)
- appending zeros to signature of ASN.1 TLV (ex. 0x3082....1fbc000000 even though 0x3082....1fbc, appending zeros are ignored.)

This vulnerability was fixed by strict ASN.1 DER checking.

Here is an assessment of this vulnerability:

- If you are not use ECDSA signature validation, this vulnerability is not affected.
- Not ASN.1 format signature like just concatenation of R and S value is not affected such as Bitcoin.
- This vulnerability is affected to all ECC curve parameters.
- Risk to accept a forged or crafted message to be signed is low.
- Risk to raise memory corruption is low since jsrsasign uses BigInteger class.
- ECDSA signatures semantically the same to valid one may be accepted as valid. There are many malleable variants.

As discussed [here](https://crypto.stackexchange.com/questions/24862/ber-or-der-x9-62-for-ecdsa-signature), there is no standards like X9.62 which requires ASN.1 DER. So ASN.1 BER can be applied to ECDSA however most of implementations like OpenSSL do strict ASN.1 DER checking.