wolfSSL with WSL (Windows Subsystem for Linux)

Microsoft has created a Linux subsystem that allows running Linux distributions on Windows 10. This blog describes the steps for building and running wolfSSL on WSL.

Installing WSL and Ubuntu 18.04:

  1. Open PowerShell as Administrator (right-click and choose “Run as Administrator”)
  2. Run the following commands:
    1. Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux
    2. Invoke-WebRequest -Uri https://aka.ms/wsl-ubuntu-1804 -OutFile Ubuntu.appx -UseBasicParsing
    3. Add-AppxPackage .\Ubuntu.appx
  3. Start -> Ubuntu 18.04 (should be at the top of the start menu)
  4. Installing, this may take a few minutes…
  5. Choose username and password
  6. Update Ubuntu:
    1. sudo apt update
    2. sudo apt upgrade

Building wolfSSL:

  1. Install prerequisites
    1. sudo apt-get install autoconf libtool make execstack
  2. git clone https://github.com/wolfSSL/wolfssl.git
  3. cd wolfssl
  4. ./autogen.sh
  5. ./configure
  6. make
  7. make check

Enabling Intel Speedups and Running Benchmarks:

  1. ./configure –enable-intelasm –enable-aesni –enable-sp –enable-sp-asm
  2. make
  3. WSL does not currently have support for the PROT_GROWSDOWN flag. Manually clear the executable stack flag in the library:
    1. execstack -c ./src/.libs/libwolfssl.so
  4. ./wolfcrypt/benchmark/benchmark

wolfTPM support for Xilinx Zynq and VxWorks

The wolfTPM library has now been tested on the Xilinx Zynq UltraScale with VxWorks. 

Testing was done using a Xilinx Zynq Pmod board with Infineon SLB9670 TPM 2.0 module. 

The TPM 2.0 module can be used for measured boot functionality and cryptographic security to extend the hardware root of trust enabled by Zynq and Zynq UltraScale+ devices.

The wolfTPM library and TPM 2.0 module can be accessed from VxWorks kernel mode and user space. 

More information on the Zynq Pmod module can be found here:

http://www.zedboard.org/product/trusted-platform-module-security-pmod

For questions please email us at facts@wolfssl.com.

Vulnerability Disclosure: TLSv1.3 PSK extension parsing potential buffer overflow

Affected Users:

User of wolfSSL v4.0.0 are affected.

Summary of issue:

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. The identity data field of the PSK extension of the packet contains data beyond the buffer length to be stored in the undefined memory (RAM) of the server. The size of the data is about 65 kB. Attackers could write about 65 kB of data to the RAM space on affected servers.

Recommendation:

Users should upgrade to wolfSSL v4.1.0 

Research:

https://nvd.nist.gov/vuln/detail/CVE-2019-11873

Additional details:

Patch for this vulnerability can be viewed here: https://github.com/wolfSSL/wolfssl/pull/2239

Please contact support@wolfssl.com if you have any questions.

Related Items:
https://www.wolfssl.com/everything-wanted-know-wolfssl-support-handles-vulnerability-reports-afraid-ask/
https://www.wolfssl.com/docs/security-vulnerabilities/
https://github.com/wolfSSL/wolfssl/pull/2353

Vulnerability Disclosure: ECDSA signing operations and nonce size leaks

Settings that mitigate this vulnerability in affected versions (secp256r1 only, all other curves are affected):

  • –enable-sp
  • –enable-sp-asm
  • –enable-fpecc

Affected Users:

Users with long-term private ECC ECDSA keys performing ECDSA sign operations with the USE_FAST_MATH setting (–enable-fastmath).

Users who have disabled the default enabled timing resistance while also using fastmath (–disable-harden) or using normal math (–disable-fastmath) will continue to be susceptible to timing attacks including this vulnerability.

Summary:

There is a potential leak of nonce sizes when performing ECDSA signing operations. The leak is considered to be difficult to exploit but it could potentially be used to recover private ECC keys in wolfSSL versions prior to release 4.1.0.

Recommendation:

Users with long-term private ECC ECDSA keys, performing ECDSA signing operations with the fastmath library should:

  1.  update to wolfSSL version 4.1.0
  2. replace any long-term private ECC ECDSA keys.
  3. Not disable timing resistance

Research:

The research for this vulnerability is not yet publicly available, a public disclosure containing more details is currently scheduled for September 2nd 2019. CVE-2019-13628 has been reserved for when the public disclosure is made available.

Additional details:

More available upon public disclosure of research. The patch fixing this issue can be viewed at this link: https://github.com/wolfSSL/wolfssl/pull/2353/files

Please contact support@wolfssl.com if you have any questions.

Related Items:
https://www.wolfssl.com/everything-wanted-know-wolfssl-support-handles-vulnerability-reports-afraid-ask/
https://www.wolfssl.com/docs/security-vulnerabilities/
https://github.com/wolfSSL/wolfssl/pull/2353

 

wolfSSL 4.1.0 Now Available

wolfSSL is excited to announce its summer release of the wolfSSL embedded SSL/TLS library version 4.1.0! As with each release, wolfSSL 4.1.0 comes with many feature additions, bug fixes, and improvements to the wolfSSL library. 

The list below outlines some of the new features and notable fixes added for version 4.1.0:

  • Fixes and updates for TLS 1.3:
    • Added additional sanity checks and alert messages for TLS 1.3
    • Major version TLS Draft is now ignored and an alert is sent if version negotiation occurs but no versions were matched
    • Added WOLFSSL_PSK_ONE_ID macro for indicating that only one identity in TLS 1.3 PSK is available and will be cached
    • Added XTIME_MS macro to simplify the tls13.c time requirement
    • Improved and refactored code related to parsing and creating TLS 1.3 client hello packets
    • TLS 1.3 version renegotiation now happens before interpreting ClientHello message
  • Fixes and additions for PCKS7:
    • Added a fix for a check on the return value when verifying PKCS7 bundle signatures (users with applications using the function wc_PKCS7_VerifySignedData should update)
    • Added the function wc_PKCS7_GetSignerSID for PKCS7 firmware bundles
    • Added PKCS7 callback functions for unwrapping of CEK and for decryption
  • Increased performance on ARM architecture:
    • Optimizations for Poly1305 and SHA-512/384 on ARM architecture using SIMD NEON extension
    • Optimizations for ChaCha20, Curve25519 and Ed 25519 on ARM architecture for performance increase
  • Added Sniffer updates:
    • Added support for the null cipher and static ECDH key exchange and new SSLWatchCb callback
    • Added cipher suite TLS_RSA_WITH_NULL_MD5 (off by default)
    • Sniffer statistics print out with the macro WOLFSSL_SNIFFER_STATS defined
  • Fixes, updates, and new functions added for OpenSSL Extra
  • Added the build flag –enable-ecccustcurves=all to enable all curve types
  • Added Java Secure Sockets Extension (JSSE) support
  • Added additional TLS alert messages sent with the macro WOLFSSL_EXTRA_ALERTS defined
  • Added CryptoCell-310 support on nRF52840
  • Added SiFive HiFive E31 RISC?V core family port
  • Added Telit IoT AppZone SDK port
  • Added the build flag –enable-blake2s for 32-bit Blake2s support
  • Added support for Ed25519ctx and Ed25519ph sign/verify algorithms as per RFC 8032

Stay tuned for more information regarding notable features and updates included with the wolfSSL 4.1.0 release. The following lists other various fixes and improvements that have been included with wolfSSL 4.1.0:

  • Compile time fixes for build case with SP math and RSA only
  • Fixes for Coverity static analysis report including explicit initialization of reported stack variables, as well as additional Coverity fixes thanks to Martin
  • Fixes for scan build warnings (i.e possible null dereference in ecc.c)
  • Resetting verify send value with a call to wolfSSL_clear function
  • Fix for extern with sp_ModExp_2048 when building with –cpp option
  • Fix for typo issue with –enable-sp=cortexm
  • Adding #pragma warning disable 4127 for tfm.c when building with Visual Studio
  • Improvements to the maximum ECC signature calculations
  • Improvements to TLS write handling in error cases which helps user application not go through with a wolfSSL_write attempt after a wolfSSL_read failure
  • Fix for read directory functions with Windows (wc_ReadDirFirst and wc_ReadDirNext)
  • Sanity check on index before accessing domain component buffer in call to wolfSSL_X509_NAME_get_entry
  • Sending fatal alert from client side on version error
  • Fix for static RSA cipher suite with PK callback and no loaded private key
  • Fix for potential memory leak in error case with the function wc_DsaKeyToDer, thanks to Chris H. for the report
  • Adjusting STRING_USER macro to remove includes of standard lib <string.h> or <stdio.h>
  • Bug fix for checking wrong allocation assignment in the function wc_PBKDF2 and handling potential leak on allocation failure. This case is only hit when the specific call to malloc fails in the function wc_PBKDF2. Thanks to Robert Altnoeder (Linbit) for the report
  • Improved length checks when parsing ASN.1 certificates
  • Improved checking of return values with TLS extension functions and error codes
  • Removing redundant calls to the generate function when instantiating and reseeding DRBG
  • Improvements for handling error return codes when reading input from transport layer
  • Improvements to efficiency of SNI extension parsing and error checking with ALPN parsing

This release of wolfSSL also includes a fix for 2 security vulnerabilities. A full detailed list of additions and bug fixes can be found in the wolfSSL README

To download and view the most recent version of wolfSSL, the wolfSSL GitHub repository can be cloned from here: https://github.com/wolfssl/wolfssl.git, and the most recent stable release can be downloaded from the wolfSSL download page here: https://www.wolfssl.com/download/.

For more information, please contact facts@wolfssl.com.

Differences between TLS 1.2 and TLS 1.3 (#TLS13)

wolfSSL's embedded SSL/TLS library has included support for TLS 1.3 since early releases of the TLS 1.3 draft. Since then, wolfSSL has remained up-to-date with the TLS 1.3 specification. In this post, the major upgrades of TLS 1.3 from TLS 1.2 are outlined below:

TLS 1.3

This protocol is defined in RFC 8446. TLS 1.3 contains improved security and speed. The major differences include:

  • The list of supported symmetric algorithms has been pruned of all legacy algorithms. The remaining algorithms all use Authenticated Encryption with Associated Data (AEAD) algorithms.
  • A zero-RTT (0-RTT) mode was added, saving a round-trip at connection setup for some application data at the cost of certain security properties.
  • Static RSA and Diffie-Hellman cipher suites have been removed; all public-key based key exchange mechanisms now provide forward secrecy.
  • All handshake messages after the ServerHello are now encrypted.
  • Key derivation functions have been re-designed, with the HMAC-based Extract-and-Expand Key Derivation Function (HKDF) being used as a primitive.
  • The handshake state machine has been restructured to be more consistent and remove superfluous messages.
  • ECC is now in the base spec  and includes new signature algorithms. Point format negotiation has been removed in favor of single point format for each curve.
  • Compression, custom DHE groups, and DSA have been removed, RSA padding now uses PSS.
  • TLS 1.2 version negotiation verification mechanism was deprecated in favor of a version list in an extension.
  • Session resumption with and without server-side state and the PSK-based ciphersuites of earlier versions of TLS have been replaced by a single new PSK exchange.

More information about wolfSSL and the TLS 1.3 protocol can be found here: https://www.wolfssl.com/docs/tls13/.

Additionally, please contact facts@wolfssl.com for any questions.

Multithread Support in wolfMQTT

The most requested feature for the wolfMQTT client library is now available! Multithreading support allows an application to create multiple threads that use the wolfMQTT client library. There is a new example that demonstrates this functionality, located in `examples/multithread/`. This example creates a thread that subscribes to a topic and then waits for incoming messages; it also creates many threads that publish a unique message to the topic. 

As a side note, wolfMQTT uses the wolfSSL embedded SSL/TLS library for SSL/TLS support.  Since wolfSSL supports TLS 1.3, your wolfMQTT-based projects can now use MQTT with TLS 1.3 on supported broker!

You can download the latest release from our website or clone on GitHub. For more information please email us at facts@wolfssl.com.

wolfSSL and the Zombie POODLE and GOLDENDOODLE Attacks

The wolfSSL library is NOT vulnerable to these attacks, thanks to previous fixes we’ve made and our extensive testing. 

Ongoing research regarding CBC padding oracle attacks against TLS will be presented in August 2019 at USENIX Security. These attacks were originally presented by Craig Young at BlackHat Asia in March 2019 (slides). 

Both attacks target the MAC and Padding used for TLS v1.2 with AES CBC cipher suites. TLS padding occurs when a record is not 16-byte aligned and is padded with the length value. The MAC uses HMAC with SHA/SHA256 to calculate an authentication code. For TLS the order of operation is MAC -> PAD -> ENCRYPT.

The attack requires a man-in-the-middle (MITM) position to employ the attack. It takes valid records and alters either MAC or Padding or cause TLS errors. If the TLS server responds differently to each of these errors then it can leak information about the plain text message.

The author Craig Young wrote a “padcheck” tool, which tests the following error cases:

  1. Invalid MAC with Valid Padding (0-length pad)
  2. Missing MAC with Incomplete/Invalid Padding (255-length pad)
  3. Typical POODLE condition (incorrect bytes followed by correct length)
  4. All padding bytes set to 0x80 (integer overflow attempt)
  5. Valid padding with an invalid MAC and a 0-length record

For wolfSSL, we respond consistently with the same alert and close the socket for each of these conditions.

The recommendation from the author is to stop using AES CBC cipher suites and start using TLS v1.3, which is supported by wolfSSL. More information about wolfSSL and TLS 1.3 can be found here: https://www.wolfssl.com/docs/tls13/

For more information about wolfSSL, please contact facts@wolfssl.com.