Siber güvenlik dünyasında sıradan bir gün daha başlarken, Okta'nın Red Team ekibinin ortaya çıkardığı HollowByte adlı güvenlik açığı, OpenSSL kullanıcılarını alarma geçirdi. Bu açık, yalnızca 11 baytlık bir TLS isteğiyle sunucu belleğinin 131 KB'a kadarını dondurarak hizmet reddi (DoS) saldırısına olanak tanıyor. Daha da kötüsü, OpenSSL bu açığı Haziran ayında yayınladığı yamalarla düzeltti ancak herhangi bir CVE numarası, güvenlik duyurusu veya değişiklik günlüğü girişi eklemedi. Bu durum, sistem yöneticilerinin ve güvenlik uzmanlarının açığı fark etmesini zorlaştırıyor.
HollowByte açığının temelinde, OpenSSL'nin TLS el sıkışma mesajlarının başlık bilgisine körü körüne güvenmesi yatıyor. Her TLS el sıkışma mesajı, 4 baytlık bir başlık taşır ve bu başlığın 3 baytı mesajın gövde uzunluğunu belirtir. Eski OpenSSL sürümleri, başlık geldiği anda, gövdenin tek bir baytı bile ulaşmadan ve el sıkışmanın kendi kontrolleri çalışmadan önce, alıcı arabelleğini belirtilen boyuta büyütüyordu. Gelen bir ClientHello için bu tavan 131 KB'dir. Ardından iş parçacığı, hiç gelmeyecek bir gövdeyi beklerken bloke olur; kimlik doğrulama, oturum veya anahtar değişimi gerçekleşmez.
HollowByte'u özellikle tehlikeli kılan, glibc ile etkileşimi. Saldırgan bağlantıyı kopardığında OpenSSL arabelleği serbest bırakır, ancak glibc küçük ve orta büyüklükteki bellek parçalarını çekirdeğe iade etmek yerine yeniden kullanım için tutar. Saldırgan her bağlantıda talep edilen boyutu değiştirerek, ayırıcının serbest bırakılan belleği yeniden kullanmasını engeller. Bu durum, heap parçalanmasına yol açar ve yerleşik set boyutu (RSS) sürekli artar. Okta'nın testlerinde, 1 GB belleğe sahip bir NGINX sunucusu, 547 MB belleğin parçalanmış halde donmasıyla OOM (bellek yetersizliği) hatası verdi. 16 GB'lık bir sunucuda ise HollowByte, bağlantı tavanını aşmadan sistem belleğinin %25'ini dondurdu. Okta Red Team bu nedenle "standart bağlantı sınırlama savunmalarının bu saldırıyı durduramayacağını" belirtiyor.
OpenSSL, HollowByte'u bir güvenlik açığı olarak sınıflandırmamayı tercih etti. Yamanın yazarı Matt Caswell'in açıklamasına göre, güvenlik ekibi bunu yalnızca bir "hata veya sertleştirme" düzeltmesi olarak ele aldı. OpenSSL'nin kendi güvenlik politikası, Kritik'ten Düşük'e dört şiddet seviyesi tanımlar; "hata veya sertleştirme" bunların arasında yer almaz. Düşük seviyeli bir sorun bile CVE, değişiklik günlüğü notu ve güvenlik açıkları sayfasında bir giriş alır. HollowByte ise bunların hiçbirine sahip değil. The Hacker News'in incelemesinde, 4.0.1 sürüm notlarında veya 23 maddelik değişiklik günlüğünde bu düzeltmeye dair hiçbir atıf bulunamadı.
Uzmanların Görüşleri
Bu tutarsızlık, Ocak ayında CVE-2025-66199 (Düşük) olarak kaydedilen TLS 1.3 sertifika sıkıştırma hatasıyla karşılaştırıldığında daha da belirginleşiyor. O hata, bağlantı başına yaklaşık 22 MiB bellek tüketimine yol açıyordu ancak dört koşulun bir araya gelmesini gerektiriyordu: sertifika sıkıştırmanın derlenmiş olması, sıkıştırma algoritmasının mevcut olması, uzantının müzakere edilmesi ve sunucularda istemci sertifikalarının istenmesi. HollowByte ise hiçbir ön koşul gerektirmiyor. Aynı 9 Haziran sürümünde, QUIC PATH_CHALLENGE işleyicisindeki sınırsız bellek büyümesi için Orta seviyeli CVE-2026-34183 atanmıştı. Her iki hata da bellek tüketimi DoS'udur; ancak biri CVE alırken diğeri almamıştır.
Detaylar ve Etkileri
Bu durum, özellikle downstream dağıtımlar için büyük bir sorun oluşturuyor. Red Hat gibi dağıtımlar, varsayılan olarak sürüm yükseltmek yerine yamaları geri taşımayı (backport) tercih eder. Bu nedenle, yamalanmış bir paket hala eski sürüm numarasını raporlar. Normalde bu sorun, CVE adlarına dayalı güvenlik duyuruları ve OVAL beslemeleri ile çözülür. HollowByte için ise bir CVE bulunmadığından, sistem yöneticileri paket değişiklik günlüğünü kontrol etmek veya bakımcıya sormak zorunda: 9 Haziran sürümüne mi geçildi yoksa yama (PR 30792, 30793, 30794) alındı mı? OpenSSL'yi kendiniz derliyorsanız, listelenen sürüme yükseltmeniz ve eski kütüphaneyi yükleyen tüm hizmetleri yeniden başlatmanız gerekiyor.
Yamanın yalnızca TLS'yi kapsadığı, DTLS'nin ise dışarıda bırakıldığı unutulmamalı. Caswell, DTLS için düzgün bir düzeltmenin çok daha kapsamlı olacağını ve projenin şimdilik bununla uğraşmamaya karar verdiğini belirtti. The Hacker News'in karşılaştırmasına göre, 3.6.2 ve 3.6.3 sürümlerindeki DTLS el sıkışma dosyası byte-byte aynı; en yeni 4.0.1'de bile DTLS yolu hala arabellek boyutunu eşin bildirdiği uzunluğa göre ayarlıyor. OpenSSL bu yolu sınıflandırmadı veya düzeltmeyi taahhüt etmedi. Sürüm notları, değişiklik günlüğü ve güvenlik açıkları sayfası bu konuda sessiz; yalnızca pull request'te bahsediliyor.
Nasıl Önlem Alınmalı?
HollowByte, OpenSSL'nin güvenlik açığı sınıflandırma sürecindeki tutarsızlıkları ve şeffaflık eksikliğini gözler önüne seriyor. Sistem yöneticileri için tek çözüm, OpenSSL'yi en güncel sürüme yükseltmek ve tüm hizmetleri yeniden başlatmak. Ayrıca, downstream dağıtımların yama durumunu dikkatle takip etmek gerekiyor. DTLS kullanıcıları ise şimdilik ek risk altında. Bu açık, siber güvenlik topluluğuna, sadece CVE numaralarına güvenmenin yeterli olmadığını, güvenlik düzeltmelerinin daha şeffaf bir şekilde duyurulması gerektiğini hatırlatıyor.
Kaynak: thehackernews.com
