Highly anticipated critical vulnerabilities in current versions of OpenSSL were downgraded to high severity by the OpenSSL Project today, which patched the flaw in version 3.0.7. OpenSSL’s advisory can be found here.
The downgrade should not lessen the rush to update current deployments, OpenSSL said, despite several mitigating factors reported by users who tested their systems for the vulnerabilities.
OpenSSL added there are no reports of public exploits for either CVE-2022-3786 or CVE-2022-3602. Both vulnerabilities are buffer overflows that could lead to crashes or in some rare cases to remote code execution; they affect functionality that processes email address name constraints in X.509 certificates.
OpenSSL is everywhere within IT, operational technology, and connected embedded systems. Many commercial and homegrown software projects include OpenSSL as their cryptographic key solution.
A blog published today by OpenSSL explains that several organizations doing testing on systems running affected versions of the crypto library reported two mitigating factors that blunted the effects of the vulnerability and led to the downgrade in severity from critical to high severity.
“Firstly, we had reports that on certain Linux distributions the stack layout was such that the 4 bytes overwrote an adjacent buffer that was yet to be used and therefore there was no crash or ability to cause remote code execution,” OpenSSL said. “Secondly, many modern platforms implement stack overflow protections which would mitigate against the risk of remote code execution and usually lead to a crash instead.”
Since OpenSSL is open source, maintainers caution there could still be a risk of remote code execution exploits.
“We have no way of knowing how every platform and compiler combination has arranged the buffers on the stack and therefore remote code execution may still be possible on some platforms,” OpenSSL said in its blog. Users who have OpenSSL 3.0 and later running under the hood of commercial software should work with their respective vendors on updates.
Several entities have published lists of affected Linux distributions and other software projects that may be impacted by the vulnerabilities, including SANS Institute and the Netherlands' National Cyber Security Centre.
“Any OpenSSL 3.0 application that verifies X.509 certificates received from untrusted sources should be considered vulnerable,” OpenSSL said. “This includes TLS clients, and TLS servers that are configured to use TLS client authentication.” OpenSSL also said that users operating TLS servers may disable TLS client authentication until fixes are applied, if appropriate within their environment.
The last critical vulnerability publicly disclosed and patched by OpenSSL was in September 2016 when an emergency security update addressed a flaw introduced by an earlier update. The patch in question introduced a dangling pointer vulnerability that could lead to server crashes or remote code execution.
2014’s Heartbleed vulnerability is one of the biggest internet-wide bugs of the 21st century. Heartbleed leaked memory to any client or server that was connected, and that exposed servers to attack. It also kicked off a major patching frenzy at the time as administrators scrambled to understand where OpenSSL was deployed within their infrastructure, and whether it could be updated before exploits were made public.
CWE-257: Storing Passwords in a Recoverable Format
RND encrypts passwords with a hardcoded weak secret key and returns the passwords in plaintext. If the server were compromised, an attacker could gain all the plaintext passwords and decrypt them.
No patches have been supplied by the vendor at this time. To mitigate risk, network administrators should limit access to the wireless management environments that use these affected products, allowing a limited set of trusted users and their authenticated clients to manage Ruckus infrastructure via a secure protocol such as HTTPS or SSH.
CVSS v3: 5.3
CWE-321: Use of Hard-coded Cryptographic Key
A built-in user called sshuser, with root privileges, exists on the RND platform. Both public and private ssh keys exist in the sshuser home directory. Anyone with the private key can access an RND server as sshuser.
No patches have been supplied by the vendor at this time. To mitigate risk, network administrators should limit access to the wireless management environments that use these affected products, allowing a limited set of trusted users and their authenticated clients to manage Ruckus infrastructure via a secure protocol such as HTTPS or SSH.
CVSS v3: 10.0
CWE-259: Use of Hard-coded Password
RND includes a jailed environment to allow users to configure devices without complete shell access to the underlying operating system. The jailed environment includes a built-in jailbreak for technicians to elevate privileges. The jailbreak requires a weak password that is hardcoded into the environment. Anyone with this password can access an RND server with root permissions.
No patches have been supplied by the vendor at this time. To mitigate risk, network administrators should limit access to the wireless management environments that use these affected products, allowing a limited set of trusted users and their authenticated clients to manage Ruckus infrastructure via a secure protocol such as HTTPS or SSH.
CVSS v3: 8.2
CWE-321: Use of Hard-coded Cryptographic Key
RND uses a secret key on the backend web server to ensure that session JWTs are valid. This secret key is hardcoded into the web server. Anyone with knowledge of the secret key could create a valid JWT, thus bypassing the typical authentication to access the server with administrator privileges.
No patches have been supplied by the vendor at this time. To mitigate risk, network administrators should limit access to the wireless management environments that use these affected products, allowing a limited set of trusted users and their authenticated clients to manage Ruckus infrastructure via a secure protocol such as HTTPS or SSH.
CVSS v3: 9.8
CWE-77: Improper Neutralization of Special Elements used in a Command ('Command Injection')
An authenticated vSZ user supplies an IP address as an argument to be run in an OS command, but this IP address is not sanitized. A user could supply other commands instead of an IP address to achieve RCE.
No patches have been supplied by the vendor at this time. To mitigate risk, network administrators should limit access to the wireless management environments that use these affected products, allowing a limited set of trusted users and their authenticated clients to manage Ruckus infrastructure via a secure protocol such as HTTPS or SSH.
CVSS v3: 9.0
