Memory corruption in NSS via DER-encoded DSA and RSA-PSS signatures
A flaw was found in the way NSS verifies certificates. That will happen both when client reads the Certificate message from the server or when server is configured to ask for client certificates and then receives one.
Firefox is not vulnerable as it uses the mozilla::pkix for certificate verification. Crucially, NSS fully parses the certificate before any other checks, so disabled signature methods or certificate types don't impact exploitability.
Any TLS and DTLS client that does use NSS built in certificate verification routines is vulnerable as well as any server that has certificate based client authentication enabled.
But the issue is not limited to TLS, any applications that use certificate verification are vulnerable, S/MIME is impacted too.
A flaw was found in the way CHACHA20-POLY1305 was implemented in NSS in versions before 3.55. When using multi-part Chacha20, it could cause out-of-bounds reads. This issue was fixed by explicitly disabling multi-part ChaCha20 (which was not functioning correctly) and strictly enforcing tag length. The highest threat from this vulnerability is to confidentiality and system availability.
An out-of-bounds write during Base64 decoding operation in the Network Security Services (NSS) library due to insufficient memory being allocated to the buffer. This results in a potentially exploitable crash.
External Reference:
https://www.mozilla.org/en-US/security/advisories/mfsa2017-10/#CVE-2017-5461
Acknowledgements:
Name: the Mozilla project Upstream: Ronald Crane
Race condition in libssl in Mozilla Network Security Services (NSS) before 3.15.4, as used in Mozilla Firefox before 27.0, Firefox ESR 24.x before 24.3, Thunderbird before 24.3, SeaMonkey before 2.24, and other products, allows remote attackers to cause a denial of service (use-after-free) or possibly have unspecified other impact via vectors involving a resumption handshake that triggers incorrect replacement of a session ticket.