피드 구독

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 Senior Principal Product Security Engineer - AI security, safety and trustworthiness, working for Red Hat Product Security Team.

 
Read full bio
UI_Icon-Red_Hat-Close-A-Black-RGB

채널별 검색

automation icon

오토메이션

기술, 팀, 인프라를 위한 IT 자동화 최신 동향

AI icon

인공지능

고객이 어디서나 AI 워크로드를 실행할 수 있도록 지원하는 플랫폼 업데이트

open hybrid cloud icon

오픈 하이브리드 클라우드

하이브리드 클라우드로 더욱 유연한 미래를 구축하는 방법을 알아보세요

security icon

보안

환경과 기술 전반에 걸쳐 리스크를 감소하는 방법에 대한 최신 정보

edge icon

엣지 컴퓨팅

엣지에서의 운영을 단순화하는 플랫폼 업데이트

Infrastructure icon

인프라

세계적으로 인정받은 기업용 Linux 플랫폼에 대한 최신 정보

application development icon

애플리케이션

복잡한 애플리케이션에 대한 솔루션 더 보기

Original series icon

오리지널 쇼

엔터프라이즈 기술 분야의 제작자와 리더가 전하는 흥미로운 스토리