Flaw in TLS library for resource-constrained environments has been patched
A security flaw in wolfSSL, the popular SSL/TLS library designed for embedded, RTOS, and IoT environments, leaves networks at risk of manipulator-in-the-middle (MitM) attacks.
The maintainers of wolfSSL have urged users with TLS 1.3 enabled for client-side connections to update to the latest version, after a researcher demonstrated how attackers could use the open source library to impersonate TLS 1.3 servers, then read or modify data passed between clients.
Gérald Doussot, principal security consultant at UK-based cybersecurity firm NCC Group, found the high-risk bug in the SanityCheckTls13MsgReceived() function of file tls13.c:6925.
The wolfSSL library is pitched as a portable way to provide fast, secure communications for IoT, smart grid, and smart home devices and systems, as well as routers, applications, games, and phones.
The resource is said to secure more than two billion connections.
Bypassing certificate validation
According to Doussot, the problem centers on the fact that wolfSSL “does not strictly enforce the TLS 1.3 client state machine”, as set out in the IETF’s summary of the legal state transitions for the TLS 1.3 client handshake.
“This permits attackers in a privileged network position to completely bypass server certificate validation,” the researcher explained in a security advisory published on Monday (August 24).
Miscreants can therefore “impersonate any TLS servers to which clients using the wolfSSL library are connecting”.
RECOMMENDED ‘Blocked content’ responses from malware defense tools pose data exfiltration risk
With server certificate validation, “the wolfSSL TLS client state machine accepts a ‘Finished’ message in the ‘WAIT_CERT_CR’ state, just after having processed an ‘EncryptedExtensions’ message”, added the researcher.
This contravenes the IETF’s RFC notes on TLS 1.3, which prescribe that resources like “wolfSSL should accept only ‘CertificateRequest’ or ‘Certificate’ messages as valid input to the state machine in the ‘WAIT_CERT_CR’ state”.
Disclosure timeline
NCC Group alerted wolfSSL to the vulnerability in its eponymous, flagship product on July 27. A fix was published on GitHub by the vendor, then successfully tested by NCC Group, the next day.
“It was not a tricky fix,” Larry Stefonic, co-founder of wolfSSL, told The Daily Swig.
“We had the fix ready in about 36 hours after the report.”
The patch was incorporated into the next major release, version 4.5.0, which landed on August 19.
The vulnerability (CVE-2020-24613) affects versions up to 4.5.0 across all wolfSSL platforms.
Read more of the latest open source software security news
“Users that have applications with client side code and have TLS 1.3 turned on, should update to the latest version of wolfSSL,” said the vendor in an accompanying GitHub advisory.
“Users that do not have TLS 1.3 turned on, or that are server side only, are NOT affected by this report.”
Despite having “two sets of our internal eyeballs on each line of code, and sometimes three,” said Stefonic, “we need people like Gerald who have the mindset and intellect to find these things.
“We encourage people to look at our code and break it.”
Version 4.5.0 of wolfSSL also assimilates fixes for an additional five vulnerabilities that pose a risk of denial-of-service (DoS) attacks, cache timing attacks, side-channel attacks, the leak of private keys, and clear application_data messages in epoch 0 being processed and returned to the application during the handshake.
The Daily Swig has contacted NCC Group for further comment and will update the article if and when we hear back.