Heap-based buffer overflow in PolarSSL 1.x before 1.2.17 and ARM mbed TLS (formerly PolarSSL) 1.3.x before 1.3.14 and 2.x before 2.1.2 allows remote SSL servers to cause a denial of service (client crash) and possibly execute arbitrary code via a long hostname to the server name indication (SNI) extension, which is not properly handled when creating a ClientHello message. NOTE: this identifier has been SPLIT per ADT3 due to different affected version ranges. See CVE-2015-8036 for the session ticket issue that was introduced in 1.3.0.

Heap-based buffer overflow in ARM mbed TLS (formerly PolarSSL) 1.3.x before 1.3.14 and 2.x before 2.1.2 allows remote SSL servers to cause a denial of service (client crash) and possibly execute arbitrary code via a long session ticket name to the session ticket extension, which is not properly handled when creating a ClientHello message to resume a session. NOTE: this identifier was SPLIT from CVE-2015-5291 per ADT3 due to different affected version ranges.

A flaw in how TLS/DTLS, when CBC-mode encryption is used, communicates was reported. This vulnerability can allow for a Man-in-the-Middle attacker to recover plaintext from a TLS/DTLS connection, when CBC-mode encryption is used.

This flaw is in the TLS specification, and not a bug in a specific implementation (as such, it affects nearly all implementations). As such, it affects all TLS and DTLS implementations that are compliant with TLS 1.1 or 1.2, or with DTLS 1.0 or 1.2. It also applies to implementations of SSL 3.0 and TLS 1.0 that incorporate countermeasures to deal with previous padding oracle attacks. All TLS/DTLS ciphersuites that include CBC-mode encryption are potentially vulnerable.

The paper indicates that with OpenSSL, a full plaintext recovery attack is possible, and with GnuTLS, a partial plaintext recovery is possible (recovering up to 4 bits of the last byte in any block of plaintext).

To perform a successful attack, when TLS is used, a large number of TLS sessions are required (target plaintext must be sent repeatedly in the same position in the plaintext stream across the sessions). For DTLS, a successful attack can be carried out in a single session. The attacker must also be located close to the machine being attacked.

Further details are noted in the paper.

Current status of fixes in various implementations:

OpenSSL has a patch in development NSS has a patch in development GnuTLS is fixed in versions 2.12.23, 3.0.28, and 3.1.7 PolarSSL is fixed in version 1.2.5 BouncyCastle has a patch that will be included in the forthcoming 1.48 version

Full paper:

http://www.isg.rhul.ac.uk/tls/TLStiming.pdf

External References:

http://www.isg.rhul.ac.uk/tls/ http://www.openssl.org/news/secadv20130205.txt https://polarssl.org/tech-updates/releases/polarssl-1.2.5-released

Memory leak in PolarSSL before 1.3.9 allows remote attackers to cause a denial of service (memory consumption) via a large number of ClientHello messages. NOTE: this identifier was SPLIT from CVE-2014-8628 per ADT3 due to different affected versions.

Buffer overflow in the sslreadrecord function in ssltls.c in PolarSSL before 1.1.8, when using TLS 1.1, might allow remote attackers to execute arbitrary code via a long packet.

PolarSSL versions prior to v1.1 use the HAVEGE random number generation algorithm. At its heart, this uses timing information based on the processor's high resolution timer (the RDTSC instruction). This instruction can be virtualized, and some virtual machine hosts have chosen to disable this instruction, returning 0s or predictable results.

The Diffie-Hellman key-exchange implementation in dhm.c in PolarSSL before 0.14.2 does not properly validate a public parameter, which makes it easier for man-in-the-middle attackers to obtain the shared secret key by modifying network traffic, a related issue to CVE-2011-5095.

A Security Bypass vulnerability exists in PolarSSL 0.99pre4 through 1.1.1 due to a weak encryption error when generating Diffie-Hellman values and RSA keys.

The RSA-CRT implementation in PolarSSL before 1.2.9 does not properly perform Montgomery multiplication, which might allow remote attackers to conduct a timing side-channel attack and retrieve RSA private keys.

From the PolarSSL Security Advisory 2013-03 advisory:

"A bug in the logic of the parsing of PEM encoded certificates in x509parsecrt() can result in an infinite loop, thus hogging processing power."

A remote attacker could use this flaw to make a TLS/SSL server using PolarSSL consume an excessive amount of CPU.

This issue was corrected in PolarSSL versions 1.1.7 and 1.2.8. (Versions prior to these are affected.)

External References:

https://polarssl.org/tech-updates/security-advisories/polarssl-security-advisory-2013-03

Array index error in the SSL module in PolarSSL before 1.2.5 might allow remote attackers to cause a denial of service via vectors involving a crafted padding-length value during validation of CBC padding in a TLS session, a different vulnerability than CVE-2013-0169.

PolarSSL 1.3.8 does not properly negotiate the signature algorithm to use, which allows remote attackers to conduct downgrade attacks via unspecified vectors.

Memory leak in PolarSSL before 1.2.12 and 1.3.x before 1.3.9 allows remote attackers to cause a denial of service (memory consumption) via a large number of crafted X.509 certificates. NOTE: this identifier has been SPLIT per ADT3 due to different affected versions. See CVE-2014-9744 for the ClientHello message issue.

The ssldecryptbuf function in library/ssltls.c in PolarSSL before 1.2.11 and 1.3.x before 1.3.8 allows remote attackers to cause a denial of service (crash) via vectors related to the GCM ciphersuites, as demonstrated using the Codenomicon Defensics toolkit.

The asn1getsequenceof function in library/asn1parse.c in PolarSSL 1.0 through 1.2.12 and 1.3.x through 1.3.9 does not properly initialize a pointer in the asn1sequence linked list, which allows remote attackers to cause a denial of service (crash) or possibly execute arbitrary code via a crafted ASN.1 sequence in a certificate.

From the PolarSSL Security Advisory 2013-03 advisory:

"A bug in the logic of the parsing of PEM encoded certificates in x509parsecrt() can result in an infinite loop, thus hogging processing power."

A remote attacker could use this flaw to make a TLS/SSL server using PolarSSL consume an excessive amount of CPU.

This issue was corrected in PolarSSL versions 1.1.7 and 1.2.8. (Versions prior to these are affected.)

External References:

https://polarssl.org/tech-updates/security-advisories/polarssl-security-advisory-2013-03