Bu kusurlardan yararlanılırsa, saldırganların hassas bilgilere yetkisiz erişim elde etmesine izin verebilir veya genellikle sorunlara neden olabilir.
geçenlerde Qualys (bulut güvenliği konusunda uzmanlaşmış bir teknoloji şirketi) bilinir kıldı ne buldun malloc'u atlamanın bir yolu ve OpenSSH 9.1'deki bir güvenlik açığını kullanarak bir geçiş başlatmak için çiftsiz koruma.
Şimdiye kadar belirlendi ki bu güvenlik açığı yalnızca "teorik"tir, çalışan bir istismar yaratma olasılığı düşük olduğundan. Aynı zamanda, çalışan bir istismar yaratma olasılığı büyük bir soru olmaya devam ediyor.
Güvenlik açığı ile ilgili olarak, belirtilen korumaları atlama hilesi çift ücretsiz ve malloc'tan ücretsiz sonra kullanın işgal edilen hafızayı yeniden tahsis etmektir ücretsiz olur olmaz options.kex_algorithms tarafından.
malloc'un bakış açısından, zaten boş olan belleği boşaltmak, okumak veya yazmak için hiçbir girişimde bulunulmaz; Ancak sshd açısından, iki farklı nesneye yönelik iki farklı işaretçi aynı bellek yığınını işaret ettiğinden ve bir nesneye yazma işlemi diğer nesnenin üzerine yazdığından, bir takma ad saldırısı meydana gelir.
Bu, bir olasılıklar dünyasının kapısını açar.
Debian kitap kurdu (glibc kodunu kullanan) üzerine araştırmamıza başladık.
malloc), ancak sonunda OpenBSD 7.2'ye geçtik çünkü OpenBSD
malloc (çok defansif programlamasına rağmen) iki özelliğe sahiptir:
bu özel ücretsiz çifte hata için özellikle ilgi çekici hale getirin:
Güvenlik açığı çift sürümden kaynaklanmaktadır ön kimlik doğrulama aşamasında bir bellek alanının. Güvenlik açığı koşulları oluşturmak için, sadece SSH istemcisinin başlığını değiştirin "SSH_BUG_CURVE2.0PAD" ve "SSH_OLD_DHGEX" bayraklarını ayarlayabilmek için "SSH-9.1-FuTTYSH_1p25519" (veya başka bir eski SSH istemcisi)'ne. Bu bayrakları ayarladıktan sonra, "options.kex_algorithms" arabelleği için bellek iki kez boşaltılır.
Qualys araştırmacıları, güvenlik açığı manipülasyonu sırasında, "%rip" işlemci kaydı üzerinde kontrol elde edebildiler, Yürütülecek bir sonraki ifadeye işaretçi içeren A. Geliştirilen exploit tekniği, kontrolün, varsayılan olarak OpenSSH 7.2 ile birlikte gelen güncel olmayan bir OpenBSD 9.1 ortamında sshd işleminin adres alanındaki herhangi bir noktaya aktarılmasına izin verir.
Hızlı güncelleme: "Rip" üzerinde keyfi kontrol elde edebildik bu hata aracılığıyla (yani sshd'lerde istediğimiz yere atlayabiliriz) adres alanı) yamalı bir OpenBSD 7.2 kurulumunda (çalışıyor
Varsayılan olarak OpenSSH 9.1). Bu hiçbir şekilde hikayenin sonu değil: bu eYalnızca 1. adım için malloc ve çift korumaları atlayın.Eminim Mümkün olabilecek veya hiç uygulanamayacak adımlar şunlardır:
– adım 2, ASLR, NX ve ROP'a rağmen rastgele kod yürütün
korumalar (bu muhtemelen bir bilgi sızıntısı gerektirecektir, ya da
aynı hata veya ikincil bir hata ile);– 3. adım, sshd korumalı alanından kaçma (küçük bir hata aracılığıyla, ya
ayrıcalıklı üst süreç veya azaltılmış çekirdek saldırısında
yüzey).
Önerilen prototipin, saldırının yalnızca ilk aşamasının uygulanması olduğu belirtiliyor: Çalışan bir açıktan yararlanma oluşturmak için ASLR, NX ve ROP koruma mekanizmalarını atlamanız ve sandbox yalıtımından çıkmanız gerekir ki bu pek olası değildir.
ASLR, NX ve ROP'u atlama sorununu çözmek, bilgi sızıntısına yol açan başka bir güvenlik açığını belirleyerek gerçekleştirilebilecek adres bilgilerinin alınmasını gerektirir. Ayrıcalıklı bir ebeveyn veya çekirdek işlemindeki bir hata, korumalı alandan çıkmaya yardımcı olabilir.
Güvenlik açığının şu şekilde çalıştığı belirtiliyor:
- -İlk olarak, ssh istemcisinin eski bir "FuTTY" istemcisi olduğunu varsayarak, compat_kex_proposal() içinde ücretsiz options.kex_algorithms.
- -İkinci olarak, options.kex_algorithms tarafından işgal edilen fragman, anahtar değişimi aşamasında “aes264-ctr” şifresi seçilerek, boyutu 128 bayt olan bir EVP_AES_KEY yapısı ile yeniden tahsis edilir. Bu yeniden tahsis ~1/32 olasılıkla gerçekleşir.
- – Üçüncüsü, kex_assemble_names() içinde (mm_getpwnamallow() aracılığıyla) options.kex_algorithms tarafından işgal edilen (ve şimdi EVP_AES_KEY yapısı tarafından işgal edilen) öbeği (yeniden) serbest bırakmak. Bu ancak ve ancak öbeğin ilk baytı '+', '-' veya '^' ise gerçekleşir (aksi takdirde kex_assemble_names() bir hata döndürür ve fatal_fr() çağrılır).
- – Dördüncü olarak, options.kex_algorithms tarafından işgal edilen (ve şimdi hala bir EVP_AES_KEY yapısı olarak başvurulan) öbeği, kimlik doğrulama sırasında 300 'A' bayt dizisi, "authctxt->user" veya "authctxt ->style" ile yeniden tahsis edin faz. Tüm EVP_AES_KEY yapısının üzerine etkili bir şekilde 'A' baytları yazan bu yeniden tahsis, ~2/32 olasılıkla gerçekleşir.
- – Son olarak, sshd EVP_Cipher()'i çağırdığında 0x4141414141414141'e atlar, çünkü EVP_AES_KEY yapısı 'A' baytlarımızın üzerine yazılan ve CRYPTO_ctr128_encrypt_ctr32() (EVP_Cipher() aracılığıyla) tarafından çağrılan bir işlev işaretçisi içerir.
Son olarak, bu konuda daha fazla bilgi edinmek istiyorsanız, ayrıntılara başvurabilirsiniz. Aşağıdaki bağlantıda.