On bir bayt, yama yapılmamış bir OpenSSL sunucusunun asla ulaşmayacak bir mesaj için 131 KB'a kadar bellek ayırmasına neden olacaktır. Okta'nın test ettiği glibc sistemlerinde bu bellek, süreç yeniden başlatılana kadar silinir.

OpenSSL şunu gönderdi:içi boş baytHaziran'da CVE, tavsiye ve buna işaret eden herhangi bir değişiklik kaydı girişi olmadan düzeltme yapıldı. Hizmet reddi hatasını bildiren ve adını veren Okta'nın Kırmızı Ekibi, ayrıntıları Perşembe günü yayınladı.

Sabit sürümler OpenSSL'dir4.0.1, 3.6.3, 3.5.7, 3.4.6 ve 3.0.21, hepsi 9 Haziran tarihli. Bu şubelerdeki sabit şubelerden önceki her sürümde bu var. Normal bir yama kanalındaki hiçbir şey sizi onlara yönlendiremez: tarayıcının eşleştireceği bir tanımlayıcı veya okunacak bir tavsiye yoktur.

Buradaki kusur, OpenSSL'in saldırganın sözüne güvenmesidir. Her TLS el sıkışma mesajı 4 baytlık bir başlık taşır ve bunun üç baytı gövdenin ne kadar uzun olacağını bildirir. Daha eski sürümler, başlık indiği anda, gövdenin tek bir baytı ortaya çıkmadan ve el sıkışmanın kendi kontrolleri yapılmadan önce alma arabelleğini belirtilen boyuta büyütüyordu.

Gelen ClientHello için tavan 131 KB'dir. Daha sonra işçi, asla gelmeyecek bir cesedi bekleyerek blokları işliyor. Kimlik doğrulama yok, oturum yok, anahtar değişimi yok.

Hafıza geri gelmiyor

Bu, başlı başına bir bağlantı tükenme saldırısıdır ve bunlar kadar eskidir.Slowloris. HollowByte'ın kalıcı olmasını sağlayan şey glibc'dir. Saldırgan bağlantıyı kestiğinde, OpenSSL arabelleği serbest bırakır, ancak glibc küçük ve orta büyüklükteki parçaları çekirdeğe geri göndermek yerine yeniden kullanmak üzere tutar.

Saldırı, iddia edilen boyutu her bağlantıda değiştiriyor ve Okta'nın testlerinde bu, ayırıcının serbest bıraktığı şeyi yeniden kullanmasını engellemek için yeterliydi. Yığın parçaları, yerleşik setin boyutu artar ve saldırgan gittikten sonra da uzun süre tırmanılmış halde kalır.

Okta'nın NGINX testinde, 1 GB'lık bir sunucu OOM tarafından öldürüldü ve 547 MB'lık bellek parçalar halinde donduruldu. 16 GB'lık bir sunucuda HollowByte, bağlantı tavanını aşmadan sistem belleğinin %25'ini kilitledi, bu nedenle Kırmızı Takım diyor ki"standart bağlantı sınırlayıcı savunmalar bunu durduramaz".

Bu rakamlar Okta'ya ait ve bunların yanında herhangi bir yararlanma kodu yayınlamadı. Hacker News, 18 Temmuz itibarıyla GitHub'da halka açık bir kavram kanıtı deposu bulamadı.

OpenSSL bunun bir güvenlik açığı olmadığına karar verdi

The çekme isteğiYamayı yazan Matt Caswell bunu açıkça ifade ediyor: Güvenlik ekibi "bunu yalnızca 'hata veya güçlendirme' düzeltmesi olarak ele almayı" seçti. OpenSSL'in kendigüvenlik politikasıKritik'ten Düşük'e kadar dört şiddet kademesi tanımlar ve "hata veya sertleşme" bunların arasında değildir.

Düşük düzeydeki bir sorun bile bir CVE, bir değişiklik günlüğü notu ve güvenlik açıkları sayfasına bir giriş kazandırır. HollowByte'ta bu üçünden hiçbiri yok. Hacker News, düzeltmeden hiç bahsetmedisürüm notlarıveya OpenSSL'lerin 23 girişinin tamamında4.0.1 değişiklik günlüğü.

OpenSSL nedenini söylemedi. Onlar için durum şu: Bağlantı başına 131 KB küçüktür, her TLS sunucusu bağlantı başına bellek ayırır ve sınırlı ayırma bir güvenlik açığı değildir. Okta'nın cevabı hafızanın asla geri gelmediğidir.

Hacker News, OpenSSL'e HollowByte'ın neden Düşük seviyenin altında önceliklendirildiğini ve düzeltmenin genişletilmiş destek 1.1.1 ve 1.0.2 dallarına ulaşıp ulaşmadığını sordu. Ayrıca Okta'ya, parçalanmanın glibc dışındaki dağıtıcılardan sağ çıkıp çıkmadığı da soruldu. Bu hikaye herhangi bir yanıtla güncellenecektir.

Projenin çizgisi göründüğünden daha ince. Ocak ayında OpenSSL atandıCVE-2025-66199Düşük olarak derecelendirilen bu hata, eş tarafından sağlanan uzunluğun doğrulamadan önce bağlantı başına yaklaşık 22 MiB değerinde bir yığın arabelleği oluşturduğu bir TLS 1.3 sertifika sıkıştırma hatasına dönüştü.

Bunu sıraya koymak için dört şeye ihtiyaç vardı: derlenen sertifika sıkıştırması, mevcut bir sıkıştırma algoritması, anlaşılan uzantı ve sunucularda istenen istemci sertifikaları. HollowByte'ın bunların hiçbirine ihtiyacı yok.

Aynı 9 Haziran sürümü atandıCVE-2026-34183QUIC PATH_CHALLENGE işleyicisinde sınırsız bellek büyümesine kadar Orta olarak derecelendirildi. Her ikisi de hafıza tüketen DoS'lardır. Her ikisinin de numarası var.

Sürüm aynı zamanda PKCS7_verify()'daki Yüksek önem dereceli ücretsiz kullanım sonrası kullanım da dahil olmak üzere 18 CVE'yi kapattı, böylece bu yukarı akışlı yapılardan birini çalıştıran herkese söylenmeden düzeltmeye sahip olunabilir.

Aşağı akış daha kötü. Kırmızı Şapkalıbelgelenmiş varsayılansürümü taşımak yerine yedeklemektir, böylece yamalı bir paket yine de oluşturulduğu sürümü rapor eder. Normalde bunu çözen şey, her ikisi de CVE adlarına anahtarlanmış olan tavsiye niteliğindeki bildirim ve OVAL yayındır. Burada anahtarlanacak bir CVE yok.

Geriye paket değişiklik günlüğü veya bakımcı kalıyor: 9 Haziran sürümünü temel alıp almadıklarını veya çekme isteği olan yamayı alıp almadıklarını sorun30792master ve 4.0 için,307933,6, 3,5 ve 3,4 için ve307943.0 için.

OpenSSL'yi kendiniz oluşturursanız, listelenen sürüme yükseltin ve eskisini yükleyen her şeyi yeniden başlatın.

Düzeltme yalnızca TLS'yi kapsar. Caswell, çekme talebinde DTLS'nin yalnız bırakıldığını, çünkü bunu doğru şekilde yapmanın çok daha istilacı olacağını ve projenin şimdilik bununla uğraşmamaya karar verdiğini yazdı. Hacker News, OpenSSL'in kaynağını 3.6.2 ve 3.6.3 etiketlerinde karşılaştırdı ve düzeltme boyunca DTLS el sıkışma dosyasının bayt bakımından aynı olduğunu buldu. En yeni sürüm olan 4.0.1'de bu yol, arabelleğini hâlâ eşin bildirdiği uzunlukta boyutlandırı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 hiçbir şey söylemiyor. Çekme isteği bunu yapar.

OpenSSL'in tetikleyicisi bunu bir protokol kusuru değil, bir dağıtım sorunu olarak adlandırıyor

Güncelleme (20 Temmuz 2026):HollowByte'ı önceliklendiren OpenSSL geliştiricisi Alexandr Nedvedicky, yayınlandıktan sonra The Hacker News'e yanıt verdi.

HollowByte'ı bu Haziran ayında CVE alan QUIC hatasından ayırdı. QUIC kusurunun bir protokol sorunu olduğunu söyledi çünkü kod kaç PATH_CHALLENGE karesinin kabul edileceğine dair bir sınır koymuyor. HollowByte, yaptığı okumada, hiçbir sınır belirlenmeden engelleme modunda bırakılan bir sunucuya geliyor; bu, protokoldeki bir kusurdan çok dağıtım seçimine daha yakın.

Raporun glibc kullanmayan OpenBSD ile ilgili önceliklendirmesini yaptı ve "glibc'den gelebilecek herhangi bir etkiyi dikkate almadığını" söyledi. Bu davranış Okta'nın davasının merkezinde yer alıyor.

Ayrıca gönderilen düzeltmenin sorunu çözeceğinden de emin değildi. Caswell'in yaması tamponu ihtiyatlı bir şekilde büyütüyor ancak yine de realloc kullanıyor ve Nedvedicky "glibc için herhangi bir gelişme olup olmadığından emin olmadığını" söyledi. Okta ne olursa olsun yükseltme yapmanızı önerir.

Düzeltmenin genişletilmiş destek 1.1.1 ve 1.0.2 dallarına ulaşıp ulaşmadığı konusunda yorum yapmayı reddetti ve OpenSSL'in destek portalını işaret etti.

OpenSSL analizini yayınlıyor

Güncelleme (24 Temmuz 2026):OpenSSL,muhakemeHollowByte raporunda.

Glibc/Linux'taki davranışı tekrarladı: Yerleşik bellek, saldıran bağlantılar kapandıktan sonra yüksekte kalıyor çünkü ayırıcı, serbest kalan belleği yeniden kullanım için tutuyor. OpenSSL testinde bu yükselme, eş zamanlı el sıkışmaların zirve noktasıyla belirlenen bir platoya ulaştı ve daha sonra rastgele mesaj boyutları ve hem yamalı hem de yamasız yapılar da dahil olmak üzere tekrarlanan turlar arasında tırmanmak yerine yeniden kullanıldı. Proje, kalan maliyeti "biriken sızıntı değil, en yüksek eşzamanlılık tarafından belirlenen sınırlı, tek seferlik bir artış" olarak tanımlıyor.

Sınıflandırmanın gerekçesi sınırsız etkiye karşı sınırlıdır. PATH_CHALLENGE sorunu sınırsız bir şekilde büyüdü ve hiçbir uygulama ayarı onu etkisiz hale getiremedi; dolayısıyla yalnızca bir kitaplık değişikliği onu kapatabilirdi. HollowByte'ın tahsisi bağlantı başına sınırlıdır ve OpenSSL, zaman aşımlarının, bağlantı sınırlarının ve engellenmeyen G/Ç'nin zaten adreslediği kesintileri yavaş bağlantı sınıfına koyar. Normal kaynaklara sahip bir ana bilgisayarda, çalışanların hafıza yetersizliğinden ziyade bitkinlik yaşadığı görüldü; Okta'nın testlerindeki OOM sonucu, hafızası kısıtlı bir kutudaydı. Sınıflandırmayı bir yargı olarak adlandırıyor ve yeni bilgilerin analizi değiştirmesi durumunda tekrar gözden geçireceğini söylüyor.

Düzeltme, halka açık çekme taleplerinde geliştirildi ve bir CVE'nin saklanması kasıtlı bir sınıflandırmaydı. Proje, açıkta geliştirilen bir düzeltmenin, bir savunmacının kolayca bulabileceği bir düzeltmeyle aynı olmadığını kabul ediyor ve o zamandan beri, değişikliği ve onu taşıyan sürümleri kaydeden bir CHANGES.md girişi eklediğini söylüyor.

İki açık soru yanıtlandı. OpenSSL 1.1.1 ve 1.0.2 genel destek kapsamı dışındadır ve müşterileri değişikliği desteklenen sürümler aracılığıyla alan genişletilmiş destek sözleşmeleri kapsamında sürdürülmektedir. DTLS, tahsisi sınırlayan mesaj başına maksimum değerle değişmeden onaylanır ve proje, buradaki artımlı işlemeyi reddedilmek yerine tamamlanmamış olarak ele alır.

OpenSSL'in nginx rakamları, her bağlantının büyük bir mesaj bildirdiği, çalışan başına en kötü durumdaki yerleşik belleğin değişiklikten önce yaklaşık 102 MB ve sonrasında 53 MB olduğunu gösteriyor; gerçekçi bir boyut karışımı altında, kabaca 70 MB'tan 55 MB'a kadar. Yönergesi, yükseltme yapmak ve ayrıca el sıkışma ve boşta kalma zaman aşımlarını ayarlamak, eşzamanlı bağlantıları sınırlamak, kaynak başına hız sınırını belirlemek ve engellenmeyen G/Ç'yi tercih etmektir.

Bu makaleyi ilginç buldunuz mu? Yayınladığımız daha fazla özel içeriği okumak için biziGoogle Haberler'de, Twitter'da and LinkedIn'detakip edin.