OpenSSL fixes two high severity vulnerabilities – OpenSSL versions 3.0.0 to 3.0.6 are vulnerable – OpenSSL 1.1.1 and 1.0.2 NOT affected

01.Nov.2022

CyberSec / ITSec / Sicherheit / Security / SPAM

BUT: only 1.5% of all OpenSSL instances were found to be impacted by this security flaw

HeartBleed revival party? why complexity is the enemy: “parser written in C was never properly tested for security problems” says golem.de

“The Heartbleed bug would not have been possible if OpenSSL had been implemented in Rust” (src)

OpenSSL versions 3.0.0 to 3.0.6 are vulnerable to this issue.
OpenSSL 3.0 users should upgrade to OpenSSL 3.0.7.
OpenSSL 1.1.1 and 1.0.2 NOT affected by this issue.

# test in terminal
hostnamectl; # tested on
  Operating System: Debian GNU/Linux 11 (bullseye)
            Kernel: Linux 5.10.0-19-amd64
      Architecture: x86-64

openssl version
OpenSSL 1.1.1n  15 Mar 2022

https://www.bleepingcomputer.com/news/security/openssl-fixes-two-high-severity-vulnerabilities-what-you-need-to-know/

The OpenSSL Project has patched two high-severity security flaws in its open-source cryptographic library used to encrypt communication channels and HTTPS connections.

The vulnerabilities (CVE-2022-3602 and CVE-2022-3786) affect OpenSSL version 3.0.0 and later and have been addressed in OpenSSL 3.0.7.

CVE-2022-3602 is an arbitrary 4-byte stack buffer overflow that could trigger crashes or lead to remote code execution (RCE), while CVE-2022-3786 can be exploited by attackers via malicious email addresses to trigger a denial of service state via a buffer overflow.

“We still consider these issues to be serious vulnerabilities and affected users are encouraged to upgrade as soon as possible,” the OpenSSL team said.

“We are not aware of any working exploit that could lead to remote code execution, and we have no evidence of these issues being exploited as of the time of release of this post.”

Per Open SSL’s policy, organizations and IT admins have been warned since October 25 to search their environments for vulnerable instances and prepare them for patching when OpenSSL 3.0.7 is released.

“If you know in advance where you are using OpenSSL 3.0+ and how you are using it then when the advisory comes you’ll be able to quickly determine if or how you’re affected and what you need to patch,” Cox said.

OpenSSL also provides mitigation measures requiring admins operating TLS servers to disable TLS client authentication until the patches are applied.

Much ado about nothing?

While the initial warning prompted admins to take immediate action to mitigate the flaw, the actual impact is much more limited given that CVE-2022-3602 (initially rated as critical) has been downgraded to high severity and it only impacts OpenSSL 3.0 and later instances.

These recently released versions are also yet to be heavily deployed to software used in production compared to earlier versions of the OpenSSL library.

Additionally, even though some security experts and vendors have equated the discovery of this vulnerability with the Log4Shell flaw in the Apache Log4J logging library, only roughly 7,000 Internet-exposed systems running vulnerable OpenSSL versions out of a total of more than 1,793,000 unique hosts spotted by Censys online — Shodan lists around 16,000 publicly accessible OpenSSL instances.

Cloud security firm Wiz.io also said that only 1.5% of all OpenSSL instances were found to be impacted by this security flaw after analyzing deployments across major cloud environments (i.e., AWS, GCP, Azure, OCI, and Alibaba Cloud).

The Netherlands’ National Cyber Security Centre is maintaining a list of software products confirmed to be (un)affected by this OpenSSL vulnerability.

The latest OpenSSL versions are included in the most recent releases of multiple popular Linux distributions, with Redhat Enterprise Linux 9, Ubuntu 22.04+, CentOS Stream9, Kali 2022.3, Debian 12 (that’s the testing release!!!), and Fedora 36 tagged as vulnerable by cybersecurity company Akamai.

Akamai has also shared OSQuery and YARA rules to help security teams find vulnerable assets and queue them for patching once the security update is released.

creditz 2 Sergiu Gatlan

how to (theoretically) manually build from src and upgrade OpenSSL

1) backup the system

2) does NOT work with Debian GNU/Linux 11 (bullseye)

openssl version
openssl: error while loading shared libraries: libssl.so.3: cannot open shared object file: No such file or directory

How to install OpenSSL 3.0.7

Unix / Linux / macOS:

su - root
apt install build-essential gcc make
wget https://github.com/openssl/openssl/archive/refs/tags/openssl-3.0.7.tar.gz
tar -zxf openssl-3.0.7.tar.gz
rm openssl-3.0.7.tar.gz
cd openssl-3.0.7
./Configure
make
make test
make install

Now you can check your own system by running the shell command: