As you may know the OpenSSL Project recently attended ICMC 23 where we were given the opportunity to update our peers about the rapid fundamental changes the project has gone through in 2023.
To summarize here are the key takeaways from our presentation:
As a part of our mission to be more open and engaged with our community, OpenSSL is pleased to announce we will be attending the International Cryptographic Module Conference 2023 or ICMC 2023 in Ottawa, Canada this week. ICMC 23 is building on a decade of cybersecurity thought leadership as the industry faces widespread changes and emerging threats in commercial cryptography.
The OpenSSL Management Committee (OMC) represents the official voice of the project and is ultimately responsible for all decisions regarding management and strategic direction of the project.
You may have already seen the recent blog post about Mark Cox leaving the OMC.
Following on from that we are delighted to announce that Anton Arapov, our engineering manager, has now joined the OMC.
You can check our website for the full list of members.
OpenSSL 1.1.1 series has reached its End of Life (EOL). As such it will no longer receive publicly available security fixes.
We are pleased to announce the immediate availability of OpenSSL 3.2 Alpha 1. This release incorporates a number of new features, most notably:
This is the end of an era for OpenSSL with the last of the original founders of the project passing on the torch to the current leadership of the project for the next phase of its evolution.
OpenSSL is pleased to announce the imminent release of OpenSSL 3.2 Alpha 1 on the 7th September 2023.
As this will be an alpha release, it is intended for development and testing purposes. It represents the first step in our planned release of OpenSSL 3.2.
Depending on the outcome of the alpha process, we hope to make a beta release as soon as two weeks after Alpha 1 is released. When we do move to beta, this will represent a feature freeze. Therefore, no new feature PRs will be accepted into the 3.2 branch after this.
More details about OpenSSL 3.2 Alpha 1 will be made available at the time of the release.
At OpenSSL, we’re always learning and taking small steps, informed by both fresh ideas and the feedback we receive. Today, we’d like to share a couple of updates we hope will make things clearer and more collaborative for our community.
These updates are part of our effort to align more closely with, and live by, our Mission and Values.
Last week marked the public announcement of the Downfall vulnerability in Intel CPUs and the Inception vulnerability in AMD CPUs. Both of these are microarchitectural side-channel attacks allowing an attacker with unprivileged execution on the same physical core as a victim process to extract confidential information from that process.
This blog post provides information and advice for users of OpenSSL. Specifically, it provides information on how users of OpenSSL may be affected by these vulnerabilities, and advice for users of OpenSSL on mitigation strategies.
Firstly, it should be noted that while the Downfall vulnerability is demoed against OpenSSL, this is a highly general microarchitectural side-channel attack which can compromise the security of essentially any software and is not specific to OpenSSL (nor is it something we could mitigate with code changes). This is not a vulnerability in OpenSSL.
This attack affects a large number of Intel processors across multiple generations, including Skylake, Tiger Lake and those generations in between. Exact details of affected models can be confirmed on the Intel website.
Note: The table lists a number of different historic side-channel vulnerabilities; the “Gather Data Sampling” (CVE-2022-40982) column is the relevant column. “MCU” means a processor is affected and that a microcode update has been issued.
If an attacker can obtain local (but unprivileged) execution on a machine with an affected CPU, and they are able to schedule that process on the same physical core as another process, and they are able to execute AVX instructions, you should assume they are able to obtain read access to any information stored within that process’s memory.
It should be stressed that this attack is entirely dependent on an adversary being able to execute code on the same physical system as a victim process; therefore, systems which only execute code installed by trusted parties are not at risk. However, virtual machines (in the absence of the mitigations advised below) are not an effective protection.
The requirement for executing on the same physical core as a victim process can be met either by OS context switching or via hyperthreading.
Because OpenSSL provides accelerated implementations of many cryptographic primitives using x86 SIMD instructions, if an attacker executes an attack using this vulnerability on a process performing cryptographic operations using OpenSSL, there is an elevated risk that the information they are able to extract will include cryptographic key material or plaintexts, as this material is likely to have been recently processed in the victim process using SIMD instructions. In other words, the risk to key material or other cryptographic material is particularly high.
However, this does not mean that other information stored in a process is not vulnerable to compromise and we would recommend that users assume that all information stored in a vulnerable process is accessible to an attacker. While there are potentially limitations to the exploitation techniques published, the qualifiers to any such limitations are sufficiently complex to be unable to make assurances in any particular area.
The following mitigations are available:
Intel have released microcode updates for affected CPUs and the best course of action to mitigate these vulnerabilities is to deploy these microcode updates as soon as possible.
In the absence of the ability to deploy these microcode updates, an alternative mitigation is to disable the ability to use AVX instructions in any untrusted process. This will generally require an OS update; for example, a mitigation patch is now available for the Linux kernel which allows this to be configured. Disabling AVX may break applications which have been designed or compiled under the assumption that AVX is available.
It should be emphasised that a victim process does not need to execute AVX instructions to be affected. Exploitation can only be mitigated by preventing an attacker process from executing AVX instructions.
The immediate indicated mitigation action is to install the microcode updates providing mitigation for this vulnerability provided by Intel, or system firmware updates incorporating those microcode updates provided by your system vendor. Further information on how to deploy these microcode updates is available below.
The disabling of AVX should be seen as a fallback mitigation where it is not feasible to deploy these microcode or system firmware updates.
The following are not effective mitigations:
It may be possible to provide mitigation by scheduling untrusted processes on separate physical cores to trusted processes, however we would not recommend trying to adopt this as a mitigation strategy, as it requires users to accurately classify trusted and untrusted processes, and to correctly configure process scheduling affinity. It would be hard for users to verify that this has been configured correctly, and there is substantial risk of misconfiguration.
An OS update may provide an indication of whether your hardware is vulnerable or not, and whether updated microcode providing mitigation for the vulnerability has been loaded. These OS updates may also provide the ability to disable AVX where such microcode updates are not loaded, but this generally needs to be explicitly requested and is not enabled by default. Note that a kernel update by itself will not load the updated microcode. Information on how to configure and verify operation for Linux-based operating systems is available here.
It is advisable to use these status reporting facilities, where available, to verify correct deployment of mitigations for this vulnerability.
It can be valuable to install these OS updates even on systems which are not affected in order to get this status reporting, as this can ease confirming whether a system is affected or not.
To deploy the microcode updates for affected processors provided by Intel, there are two options:
Install a system firmware update which incorporates these microcode updates provided by your system vendor. These updates will automatically deploy the microcode update at boot time. This is the preferred option.
Alternatively, if a firmware update is not available from your system vendor, you can install the Intel microcode update yourself using the procedures specific to your OS. Note that microcode updates need to be applied on every boot.
Note also that it is generally advised to apply microcode updates as early as possible in the boot process.
You can confirm correct deployment of microcode using the mitigation status reporting mechanism provided by your (updated) OS, if your OS provides one, as discussed above.
Alternatively, you can verify the reported running microcode version numbers directly where your OS provides facilities to do so. Refer to the Intel bulletin for patched microcode version numbers.
Although announced at the same time as the Downfall attack, this attack is a separate microarchitectural side-channel attack which is unrelated to Downfall and does not rely on AVX functionality.
This attack affects Zen 1, 2, 3 and 4.
Similarly to the Downfall attack, successful exploitation of this vulnerability requires an attacker have local (though unprivileged) execution on an affected CPU. If an attacker is able to obtain local unprivileged execution on an affected system, you should assume they are able to obtain read access to any information stored in memory. For example, the attack can be used to obtain information stored in the kernel, or in other processes, or file contents cached in memory by the kernel.
It should be stressed that this attack is entirely dependent on an adversary being able to execute code on the same physical system as a victim process; therefore, systems which only execute code installed by trusted parties are not at risk. However, virtual machines (in the absence of the mitigations advised below) are not an effective protection.
An OS update is always required (and always sufficient) to fully mitigate this vulnerability.
The immediate indicated mitigation action is to install the updates providing mitigation for this vulnerability provided by your OS vendor as soon as they become available.
AMD has also released microcode updates for Zen 3 and 4. Installing these updates is not essential to effective mitigation of this vulnerability, as OS updates alone are capable of adequate mitigation. However, installing these updates may improve performance when mitigations for this vulnerability are enabled. In any case, installation of these updates is recommended.
These microcode updates are not needed for Zen 1 and 2.
Installing microcode updates alone does not provide adequate mitigation.
To reiterate, the indicated mitigation actions are as follows:
Once an OS update is installed, the update may be able to provide an indication of whether your hardware is vulnerable or not and, if so, whether mitigations are in place. Information on how to configure and verify operation for Linux-based operating systems is available here.
It is advisable to use these status reporting facilities, where available, to verify correct deployment of mitigations for this vulnerability.
For Linux, the “safe RET” and “IBPB” mitigation levels correspond to full mitigation of this vulnerability. All other mitigation levels provide only partial protection. The string “no microcode” will also appear in the status string if a microcode update is desirable but not present.
It can be valuable to install these OS updates even on systems which are not affected in order to get this status reporting, as this can ease confirming whether a system is affected or not.
To deploy the microcode updates for Zen 3 and 4 provided by AMD, there are two options:
Install a system firmware update which incorporates these microcode updates provided by your system vendor. These updates will automatically deploy the microcode update at boot time. This is the preferred option.
Alternatively, if a firmware update is not available from your system vendor, you can install the AMD microcode update yourself using the procedures specific to your OS. Note that microcode updates need to be applied on every boot.
Note also that it is generally advised to apply microcode updates as early as possible in the boot process.
You can confirm correct deployment of microcode using the mitigation status reporting mechanism provided by your (updated) OS, if your OS provides one, as discussed above.
Alternatively, you can verify the reported running microcode version numbers directly where your OS provides facilities to do so. Refer to the AMD bulletin for patched microcode version numbers.
We recently published our mission statement and values which included that our governance should be transparent. We’ve not really talked much about how we’re financed and where the money goes, so let’s make a start on changing that.
A little background for clarity: The OpenSSL project has two companies, registered in the USA. The first, OpenSSL Software Foundation, is a non-profit organisation that is used to hold the copyrights, trademarks, as well as things like the contributor license agreements (CLA). The second, OpenSSL Software Services, is our commercial entity that provides companies with paid support and other services, and pays our consultants to work on those services as well as development on OpenSSL. The OpenSSL project relies on funding to maintain and improve OpenSSL, and the goal of OpenSSL Software Services is to ensure long term sustainable funding to the project.
The Heartbleed vulnerability in 2014 highlighted the lack of funding of OpenSSL. The Linux Foundation therefore started the Core Infrastructure Initiative (CII) to gather funding from organisations, and they paid for two full time people to work on OpenSSL for three years, as well as a security audit. While we were extremely grateful for this at a critical time in the project, we knew that this model, and the funding itself, was going to only be a short-term interim measure. We have experimented with different ways to generate revenue ourselves, such as by accepting contracts (or sponsors) for specific features, such as platform support and FIPS. While these are helpful, they didn’t lead to reliable sustainable revenue.
We have organisations sponsoring us, both large corporate sponsors and smaller donations via GitHub sponsors. These vary year to year, and at the time of publishing this blog we have one platinum sponsor, one gold, three silver, and three bronze. There are also some organisations that provide their services at no or reduced cost. This funding helps to maintain the hardware and infrastructure but isn’t sufficient or stable enough to hire people.
So since 2020, our main source of income is by selling support contracts. Companies can purchase a contract if they need technical help with OpenSSL or if they need access to support for older end of life versions such as OpenSSL 1.0.2. Another driver for taking out such contracts is FIPS, where companies may wish to have FIPS compliant products with OpenSSL by rebranding our OpenSSL 3 FIPS certificate.
At the time of writing this blog we have just over 70 active support contracts. This has increased significantly in the last year. We started with a much smaller number of contracts mostly from companies that were using OpenSSL 1.0.2 and looking to have a year or two of backported fixes and support while they transitioned to OpenSSL 3. This year we gained a number of contracts from companies looking to use OpenSSL 3 and needing a rebranded FIPS certificate. Currently we’re getting interest from companies looking for short-term transitional support as they move from OpenSSL 1.1.1 (which becomes end of life later this calendar year). The needs of our customers will change over time, and we have to keep making sure we deliver value to our customers year on year.
This funding allows us to pay for eight consultants (at the time of writing this blog) to work full time on OpenSSL on engineering, management, and administration. Given the increased number of contracts this year we expect more positions to open up and we have a further 3 or 4 positions we are currently conducting interviews for. We also have other usual expenses (such as legal, administrative), as well as larger expenses (such as for services relating to FIPS certification and travel for conferences and face to face meetings).
We’re really glad that we’ve been able to move to a model where the OpenSSL project has a sustainable income source for the near future, helping us deliver on our important mission and values, to give everyone access to security and privacy tools.