Filtered by vendor Wolfssl
Subscriptions
Filtered by product Wolfssl
Subscriptions
Total
57 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2016-7438 | 1 Wolfssl | 1 Wolfssl | 2024-08-06 | N/A |
| The C software implementation of ECC in wolfSSL (formerly CyaSSL) before 3.9.10 makes it easier for local users to discover RSA keys by leveraging cache-bank hit differences. | ||||
| CVE-2016-7439 | 1 Wolfssl | 1 Wolfssl | 2024-08-06 | N/A |
| The C software implementation of RSA in wolfSSL (formerly CyaSSL) before 3.9.10 makes it easier for local users to discover RSA keys by leveraging cache-bank hit differences. | ||||
| CVE-2016-7440 | 4 Debian, Mariadb, Oracle and 1 more | 4 Debian Linux, Mariadb, Mysql and 1 more | 2024-08-06 | 5.5 Medium |
| The C software implementation of AES Encryption and Decryption in wolfSSL (formerly CyaSSL) before 3.9.10 makes it easier for local users to discover AES keys by leveraging cache-bank timing differences. | ||||
| CVE-2017-6076 | 1 Wolfssl | 1 Wolfssl | 2024-08-05 | N/A |
| In versions of wolfSSL before 3.10.2 the function fp_mul_comba makes it easier to extract RSA key information for a malicious user who has access to view cache on a machine. | ||||
| CVE-2017-2800 | 1 Wolfssl | 1 Wolfssl | 2024-08-05 | 9.8 Critical |
| A specially crafted x509 certificate can cause a single out of bounds byte overwrite in wolfSSL through 3.10.2 resulting in potential certificate validation vulnerabilities, denial of service and possible remote code execution. In order to trigger this vulnerability, the attacker needs to supply a malicious x509 certificate to either a server or a client application using this library. | ||||
| CVE-2018-16870 | 1 Wolfssl | 1 Wolfssl | 2024-08-05 | N/A |
| It was found that wolfssl before 3.15.7 is vulnerable to a new variant of the Bleichenbacher attack to perform downgrade attacks against TLS. This may lead to leakage of sensible data. | ||||
| CVE-2019-19960 | 1 Wolfssl | 1 Wolfssl | 2024-08-05 | 5.3 Medium |
| In wolfSSL before 4.3.0, wc_ecc_mulmod_ex does not properly resist side-channel attacks. | ||||
| CVE-2019-19962 | 1 Wolfssl | 1 Wolfssl | 2024-08-05 | 7.5 High |
| wolfSSL before 4.3.0 mishandles calls to wc_SignatureGenerateHash, leading to fault injection in RSA cryptography. | ||||
| CVE-2019-19963 | 1 Wolfssl | 1 Wolfssl | 2024-08-05 | 5.3 Medium |
| An issue was discovered in wolfSSL before 4.3.0 in a non-default configuration where DSA is enabled. DSA signing uses the BEEA algorithm during modular inversion of the nonce, leading to a side-channel attack against the nonce. | ||||
| CVE-2019-18840 | 1 Wolfssl | 1 Wolfssl | 2024-08-05 | 7.5 High |
| In wolfSSL 4.1.0 through 4.2.0c, there are missing sanity checks of memory accesses in parsing ASN.1 certificate data while handshaking. Specifically, there is a one-byte heap-based buffer overflow inside the DecodedCert structure in GetName in wolfcrypt/src/asn.c because the domain name location index is mishandled. Because a pointer is overwritten, there is an invalid free. | ||||
| CVE-2019-16748 | 1 Wolfssl | 1 Wolfssl | 2024-08-05 | 9.8 Critical |
| In wolfSSL through 4.1.0, there is a missing sanity check of memory accesses in parsing ASN.1 certificate data while handshaking. Specifically, there is a one-byte heap-based buffer over-read in CheckCertSignature_ex in wolfcrypt/src/asn.c. | ||||
| CVE-2019-15651 | 1 Wolfssl | 1 Wolfssl | 2024-08-05 | N/A |
| wolfSSL 4.1.0 has a one-byte heap-based buffer over-read in DecodeCertExtensions in wolfcrypt/src/asn.c because reading the ASN_BOOLEAN byte is mishandled for a crafted DER certificate in GetLength_ex. | ||||
| CVE-2019-14317 | 1 Wolfssl | 1 Wolfssl | 2024-08-05 | 5.3 Medium |
| wolfSSL and wolfCrypt 4.1.0 and earlier (formerly known as CyaSSL) generate biased DSA nonces. This allows a remote attacker to compute the long term private key from several hundred DSA signatures via a lattice attack. The issue occurs because dsa.c fixes two bits of the generated nonces. | ||||
| CVE-2019-13628 | 1 Wolfssl | 1 Wolfssl | 2024-08-04 | 4.7 Medium |
| wolfSSL and wolfCrypt 4.0.0 and earlier (when configured without --enable-fpecc, --enable-sp, or --enable-sp-math) contain a timing side channel in ECDSA signature generation. This allows a local attacker, able to precisely measure the duration of signature operations, to infer information about the nonces used and potentially mount a lattice attack to recover the private key used. The issue occurs because ecc.c scalar multiplication might leak the bit length. | ||||
| CVE-2019-11873 | 1 Wolfssl | 1 Wolfssl | 2024-08-04 | 9.8 Critical |
| wolfSSL 4.0.0 has a Buffer Overflow in DoPreSharedKeys in tls13.c when a current identity size is greater than a client identity size. An attacker sends a crafted hello client packet over the network to a TLSv1.3 wolfSSL server. The length fields of the packet: record length, client hello length, total extensions length, PSK extension length, total identity length, and identity length contain their maximum value which is 2^16. The identity data field of the PSK extension of the packet contains the attack data, to be stored in the undefined memory (RAM) of the server. The size of the data is about 65 kB. Possibly the attacker can perform a remote code execution attack. | ||||
| CVE-2019-6439 | 1 Wolfssl | 1 Wolfssl | 2024-08-04 | N/A |
| examples/benchmark/tls_bench.c in a benchmark tool in wolfSSL through 3.15.7 has a heap-based buffer overflow. | ||||
| CVE-2020-36177 | 1 Wolfssl | 1 Wolfssl | 2024-08-04 | 9.8 Critical |
| RsaPad_PSS in wolfcrypt/src/rsa.c in wolfSSL before 4.6.0 has an out-of-bounds write for certain relationships between key size and digest size. | ||||
| CVE-2020-24585 | 1 Wolfssl | 1 Wolfssl | 2024-08-04 | 5.3 Medium |
| An issue was discovered in the DTLS handshake implementation in wolfSSL before 4.5.0. Clear DTLS application_data messages in epoch 0 do not produce an out-of-order error. Instead, these messages are returned to the application. | ||||
| CVE-2020-24613 | 1 Wolfssl | 1 Wolfssl | 2024-08-04 | 6.8 Medium |
| wolfSSL before 4.5.0 mishandles TLS 1.3 server data in the WAIT_CERT_CR state, within SanityCheckTls13MsgReceived() in tls13.c. This is an incorrect implementation of the TLS 1.3 client state machine. This allows attackers in a privileged network position to completely impersonate any TLS 1.3 servers, and read or modify potentially sensitive information between clients using the wolfSSL library and these TLS servers. | ||||
| CVE-2020-15309 | 1 Wolfssl | 1 Wolfssl | 2024-08-04 | 7.0 High |
| An issue was discovered in wolfSSL before 4.5.0, when single precision is not employed. Local attackers can conduct a cache-timing attack against public key operations. These attackers may already have obtained sensitive information if the affected system has been used for private key operations (e.g., signing with a private key). | ||||