CVE-2020-15309: Release wolfSSL Release 4.5.0 (08/19/2020) · wolfSSL/wolfssl

wolfSSL Release 4.5.0 (August 19, 2020)

If you have questions about this release, feel free to contact us on our
info@ address.

Release 4.5.0 of wolfSSL embedded TLS has bug fixes and new features including:

New Feature Additions

• Added Xilinx Vitis 2019.2 example and README updates
• TLS v1.3 is now enabled by default
• Building FIPS 140-2 code and test on Solaris
• Secure renegotiation with DTLS 1.2
• Update RSA calls for hardware acceleration with Xilsecure
• Additional OpenSSL compatibility layer functions added
• Cypress PSoC6 wolfCrypt driver added
• Added STM32CubeIDE support
• Added certificate parsing and inspection to C# wrapper layer
• TLS v1.3 sniffer support added
• TSIP v1.09 for target board GR-ROSE support added
• Added support for the “X72N Envision Kit” evaluation board
• Support for ECC nonblocking using the configure options
  “–enable-ecc=nonblock --enable-sp=yes,nonblock CFLAGS=-DWOLFSSL_PUBLIC_MP”
• Added wc_curve25519_make_pub function to generate a public key given the
  private one

Fixes

• PIC32MZ hardware cache and large hashes fix
• AES-GCM use with EVP layer in compatibility layer code
• Fix for RSA_LOW_MEM with ARM build of SP code
• Sanity check on tag length with AES-CCM to conform with RFC 3610
• Fixes for 32 and 64 bit software implementations of SP code when
  WOLFSSL_SP_CACHE_RESISTANT is defined
• GCC warning fixes for GCC 9 and later
• Sanity check on HKDF expand length to conform with RFC 5869
• Fixes for STM32 CubeMX HAL with AES-GCM
• Fixed point cache look up table (LUT) implementation fixes
• Fix for ARM 32bit SP code when calling div word
• Fix for potential out of bounds read when parsing CRLs
• Fix for potential out of bounds read with RSA unpadding
• AES-CCM optimized counter fix
• Updates to Xcode projects for new files and features
• Fix for adding CRL’s to a WOLFSSL_X509_STORE structure
• FIPSv2 build with opensslall build fixes
• Fixes for CryptoCell use with ECC and signature wrappers
• Fix for mod calculation with SP code dealing with 3072 bit keys
• Fix for handling certificates with multiple OU’s in name
• Fix for SP math implementation of sp_add_d and add a sanity check on
  rshb range
• Fix for sanity check on padding with DES3 conversion of PEM to DER
• Sanity check for potential out of bounds read with fp_read_radix_16
• Additional checking of ECC scalars.
• Fixing the FIPS Ready build w.r.t. ecc.c.
• When processing certificate names with OpenSSL compatibility layer
  enabled, unknown name item types were getting handled as having NID 0,
  and failing. Added a couple more items to what is handled correctly,
  and ignoring anything that is an unknown type.

Improvements/Optimizations

• TLS 1.3 certificate verify update to handle 8192 bit RSA keys
• wpa_supplicant support with reduced code size option
• TLS 1.3 alerts encrypted when possible
• Many minor coverity fixes added
• Error checking when parsing PKCS12 DER
• IAR warning in test.c resolved
• ATECC608A improvements for use with Harmony 3 and PIC32 MZ
• Support for AES-GCM and wc_SignatureVerifyHash with static memory and no
  malloc’s
• Enable SNI by default with JNI/JSSE builds
• NetBSD GCC compiler warnings resolved
• Additional test cases and code coverage added including curve25519 and
  curve448 tests
• Option for user defined mutexes with WOLFSSL_USER_MUTEX
• Sniffer API’s for loading buffer directly
• Fixes and improvements from going through the DO-178 process were added
• Doxygen updates and fixes for auto documentation generation
• Changed the configure option for FIPS Ready builds to be
  –enable-fips=ready.

This release of wolfSSL includes fixes for 6 security vulnerabilities.

wolfSSL version 4.5.0 contains 6 vulnerability fixes: 2 fixes for TLS 1.3,
2 side channel attack mitigations, 1 fix for a potential private key leak
in a specific use case, 1 fix for DTLS.

• In earlier versions of wolfSSL there exists a potential man in the middle
  attack on TLS 1.3 clients. Malicious attackers with a privileged network
  position can impersonate TLS 1.3 servers and bypass authentication. Users
  that have applications with client side code and have TLS 1.3 turned on,
  should update to the latest version of wolfSSL. Users that do not have
  TLS 1.3 turned on, or that are server side only, are NOT affected by this
  report. Thanks to Gerald Doussot from NCC group for the report.
• Denial of service attack on TLS 1.3 servers from repetitively sending
  ChangeCipherSpecs messages. This denial of service results from the
  relatively low effort of sending a ChangeCipherSpecs message versus the
  effort of the server to process that message. Users with TLS 1.3 servers are
  recommended to update to the most recent version of wolfSSL which limits the
  number of TLS 1.3 ChangeCipherSpecs that can be received in order to avoid
  this DoS attack. CVE-2020-12457 was reserved for the report. Thanks to
  Lenny Wang of Tencent Security Xuanwu LAB.
• Potential cache timing attacks on public key operations in builds that are
  not using SP (single precision). Users that have a system where malicious
  agents could execute code on the system, are not using the SP build with
  wolfSSL, and are doing private key operations on the system (such as signing
  with a private key) are recommended to regenerate private keys and update to
  the most recent version of wolfSSL. CVE-2020-15309 is reserved for this
  issue. Thanks to Ida Bruhns from Universität zu Lübeck for the report.
• When using SGX with EC scalar multiplication the possibility of side-channel
  attacks are present. To mitigate the risk of side channel attacks wolfSSL’s
  single precision EC operations should be used instead. Release 4.5.0 turns
  this on be default now with SGX builds and in previous versions of wolfSSL
  this can be turned on by using the WOLFSSL_SP macros. Thank you to
  Alejandro Cabrera Aldaya, Cesar Pereida García and Billy Bob Brumley from
  the Network and Information Security Group (NISEC) at Tampere University for
  the report.
• Leak of private key in the case that PEM format private keys are bundled in
  with PEM certificates into a single file. This is due to the
  misclassification of certificate type versus private key type when parsing
  through the PEM file. To be affected, wolfSSL would need to have been built
  with OPENSSL_EXTRA (–enable-opensslextra). Some build variants such as
  –enable-all and --enable-opensslall also turn on this code path, checking
  wolfssl/options.h for OPENSSL_EXTRA will show if the macro was used with the
  build. If having built with the opensslextra enable option and having placed
  PEM certificates with PEM private keys in the same file when loading up the
  certificate file, then we recommend updating wolfSSL for this use case and
  also recommend regenerating any private keys in the file.
• During the handshake, clear application_data messages in epoch 0 are
  processed and returned to the application. Fixed by dropping received
  application_data messages in epoch 0. Thank you to Paul Fiterau of Uppsala
  University and Robert Merget of Ruhr-University Bochum for the report.

For additional vulnerability information visit the vulnerability page at
https://www.wolfssl.com/docs/security-vulnerabilities/

See INSTALL file for build instructions.
More info can be found on-line at https://wolfssl.com/wolfSSL/Docs.html