OpenSSL: Email address buffer overflow security flaws

The OpenSSL project published two important impact security flaws on November 1, 2022. Since Heartbleed was released, OpenSSL security flaws grab the attention of customers, media, and the community users of this software.

OpenSSL provided pre-notification days before the issue was public, and they followed up with a blog to explain why the CVE was later split into two CVEs and downgraded. Due to the amount of material on the internet, it becomes difficult to understand everything going around this issue. The intent of this blog is to put things into perspective for our customers and community members to understand what is happening, what the risks are, and how to mitigate them.

About the security flaws

The security flaws manifest similarly, both being buffer overflows with X.509 certificates that are verified by OpenSSL when checking name constraints. This occurs after the certificate chain signature verification, and either requires a Certificate Authority (CA) to have signed the malicious certificate or for the application to continue certificate verification, despite failure to construct a path to a trusted issuer. The attacker needs to craft a malicious email address in a certificate to trigger this flaw. Overall, all of the above conditions make real world exploitation difficult to execute.

Who is at risk?

The affected code was introduced in OpenSSL in 2019, and was not backported to older versions. Only OpenSSL 3.x is affected by this flaw. Currently, the only Red Hat product shipping with this version is Red Hat Enterprise Linux 9, which additionally impacts Universal Base Image 9 and other container images with OpenSSL within them. Therefore, other versions are not affected.

Any application linked with OpenSSL in Red Hat Enterprise Linux 9 that verifies X.509 certificates received from untrusted sources should be considered vulnerable. This includes Transport Layer Security (TLS) clients and servers that are configured to use TLS client authentication.

How much risk are we talking about?

The flaw is a 4 byte stack-based buffer overwrite. Initially, upstream OpenSSL classified this flaw as critical impact, due to the fact that it could lead to remote code execution. In Red Hat Enterprise Linux 9, the presence of StackGuard and compiler optimization reduces this issue to application crash, or in some cases no crash at all. The compiler optimizes the placement of variables in such a way that the affected buffer is closest to the stack cookies, meaning that an overflow in the buffer does not affect other variables (the overwrite only affects the padding between the variables).

Therefore, exposure to remote code execution is not expected.

How do I fix this?

There is no sane way to mitigate this apart from upgrading to the newer packages which were released shortly after the issues went public. One could argue that if your application does not process X.509 certificates from unknown sources, you may not be affected. However, we would strongly advise our customers to upgrade to the latest version as soon as possible.

How Red Hat is adding value

• Making changes to software and configuration of production systems is hard, and there is always a risk of unplanned downtime that results in loss of business and productivity. Due to this reason, after OpenSSL sent a pre-notification about their upcoming issue, we published a similar bulletin for our customers, clearly stating the versions and packages affected. This helps our customers plan downtime for package updates in advance and helps minimize surprises.
• Our Security Bulletin and this blog contain all the important information needed by our customers to make the right decision about upgrades.
• During the week prior to the public release date, Red Hat performed a technical assessment of the vulnerability and how we build OpenSSL in RHEL 9. We did not believe that these were critical severity CVEs, and were pleased to see on release day that they had been adjusted to high by the OpenSSL upstream security team.
• Lastly, we realize that open source projects may have a limitation on resources, therefore, they may not be able to run several secure development processes on their code bases before shipping them. Red Hat Secure Development processes work to detect and mitigate these kinds of issues in future.

Conclusion

OpenSSL and Red Hat’s pre-notification helped our customers prepare for the upgrade. There was slight confusion about downgrading the severity level and split of CVEs, but there are always multiple scenario verifications to provide the best risk assessment to our customers. This may result in last minute changes or updates.

Huzaifa Sidhpurwala is a principal Product Security Engineer, working for Red Hat Product Security Team.

Read full bio