Many Dell, HP and Lenovo devices use old and insecure versions of OpenSSL, as Binarly warns.

Let me remind you that we also wrote that OpenSSL Fixes First Critical Vulnerability Since 2016, and also that OpenSSL Patches Released and Critical Vulnerability Turns Out to be Not So Critical.

The problem lies in the EFI Development Kit II (EDK II) open-source environment, since EDK II comes with its own cryptographic package, CryptoPkg, which, in turn, relies on OpenSSL. As a result, according to the researchers, the firmware associated with corporate Lenovo Thinkpad devices uses three different versions of OpenSSL at once (0.9.8zb, 1.0.0a and 1.0.2j), the newest of which was released in 2018.

Moreover, one of the firmware modules (InfineonTpmUpdateDxe) does rely on OpenSSL version 0.9.8zb, released on August 4, 2014.

In addition to the OpenSSL versions listed, some Lenovo and Dell firmware also use an even older version (0.9.8l) that was released on November 5, 2009. The HP firmware code also used a 10-year-old version of OpenSSL (0.9.8w).

Binarly’s report highlights that the issue that was discovered clearly illustrates a situation where third-party dependencies significantly complicate the supply chain ecosystem, as in this case.

The post Dell, HP, and Lenovo Devices Use Older Versions of OpenSSL appeared first on Gridinsoft Blog.

Now that OpenSSL 3.0.7 has been officially released, it turned out that fixes were released for two serious vulnerabilities at once, and the critical bug rating was revised, and it is no longer considered as such.

Version 3.0.7 fixed two vulnerabilities at once (CVE-2022-3602 and CVE-2022-3786) affecting OpenSSL versions 3.0.0 and higher (from 3.0.0 to 3.0.6).

Critical status should have been CVE-2022-3602, which is an arbitrary 4-byte stack buffer overflow that can cause crashes or lead to arbitrary code execution (RCE).

Ultimately, this vulnerability was rated high severity since according to the rules, a critical bug should affect widespread configurations, and only instances of OpenSSL 3.0 and later are vulnerable to CVE-2022-3602.

The second issue, CVE-2022-3786, can be exploited by a potential attacker through malicious email addresses and is capable of causing a denial of service through a buffer overflow.

Despite the assurances of the developers, some information security experts and vendors were quick to equate the discovery of a vulnerability in OpenSSL with the sensational Log4Shell problem, discovered in 2021 in the Log4J library.

Bleeping Computer notes that such a panic is premature: according to Censys, only about 7,000 systems running vulnerable versions of OpenSSL can be found on the network (among more than 1,793,000 unique hosts), and according to Shodan, there are about 16 such instances.

Cloud security company Wiz.io analysed deployments in major cloud environments (such as AWS, GCP, Azure, OCI, and Alibaba Cloud) and also reports that only 1.5% of all OpenSSL instances are affected by the latest vulnerability.

A separate page dedicated to CVE-2022-3602 and all related data was launched by well-known information security expert Marcus Hutchins. He explains that the problem occurs when validating an X.509 certificate and can be used to execute code using a malicious TLS certificate remotely. However, exploitation requires the malicious TLS certificate to be signed by a trusted CA.

The National Cybersecurity Center of the Netherlands has already begun compiling a list of products that are either affected or not affected by the latest bug.

It is worth saying that Akamai analysts have classified Redhat Enterprise Linux 9, Ubuntu 22.04+, CentOS Stream9, Kali 2022.3, Debian 12 and Fedora 36 distributions as vulnerable. The company’s experts have already published OSQuery and YARA rules that should help security specialists detect vulnerable products.

The post OpenSSL Patches Released and Critical Vulnerability Turns Out to be Not So Critical appeared first on Gridinsoft Blog.

The release of OpenSSL version 3.0.7 is scheduled for Tuesday, November 1, 2022. No details about this release have been published yet: it is described as a “security release” that will include a patch for some bug that is rated as “critical”.

Let me remind you that we also talked about the iOS VPN Bug Prevents Encryption of Traffic for Years, Researchers Say.

It is also reported that the latest issue does not affect OpenSSL 3.0 and older versions.

In addition to the release of version 3.0.7, the OpenSSL developers are also preparing version 1.1.1s. Its release is scheduled for the same day and will include patches for various bugs.

It is noteworthy that this will be the first critical vulnerability fixed in OpenSSL since September 2016, and only the second critical vulnerability in the history of the project.

Let me remind you that the OpenSSL project began assigning severity ratings to vulnerabilities only in 2014, after the discovery of the sensational Heartbleed problem (CVE-2014-0160).

The vulnerability was related to the lack of required bounds checking in one of the Heartbeat (RFC6520) extension procedures for the TLS/DTLS protocol. Due to a small bug, anyone could access the RAM of computers whose communications are “protected” by a vulnerable version of OpenSSL. In particular, the attacker gained access to secret keys, usernames and passwords, and all content that should be transmitted in encrypted form. At the same time, there were no traces of penetration into the system. Information security experts suggest something similar this time.

Since 2014 and 2017, more than a dozen high-severity issues have been identified. After that, for several years, security experts did not find a single vulnerability with a high degree of severity, and this status was assigned to only two errors in 2020. Three more high-severity issues were discovered in 2021, and two more in 2022.

The post OpenSSL Fixes First Critical Vulnerability Since 2016 appeared first on Gridinsoft Blog.