OpenSSL güvenlik açıkları ‘korkulduğu kadar kötü değil’

Yaygın olarak kullanılan açık kaynaklı şifreleme kitaplığı OpenSSL’nin arkasındaki ekip, daha önce güvenlik ekiplerini bu konuda önceden uyarmak gibi alışılmadık bir adım atmış olduğu hizmetteki iki güvenlik açığını düzeltti.

OpenSSL, Heartbleed’den bu yana kütüphanede açıklanan ilk kritik güvenlik açığı olan kritik bir güvenlik açığını düzeltmeye hazırlandığını söyleyerek Ekim ayının sonuna doğru bir danışma belgesi yayınladı.

Heartbleed hatıraları, birçok kişinin benzer önemli bir sorundan şüphelenmesine neden oldu, ancak bu durumda, açıklama yaygın paniğe neden olmadan geçti ve güvenlik açığının ilk kritik durumu yüksek seviyeye indirildi.

OpenSSL 3.0.6’dan OpenSSL 3.0.7’ye güncelleme, Punycode kod çözme işlevlerinde iki farklı arabellek taşması güvenlik açığını giderir. Bu güvenlik açıkları sırasıyla CVE-2022-3602 ve CVE-2022-3786 olarak izlenir.

CVE-2022-3602, bir X.509 aktarım katmanı güvenlik (TLS) sertifikasının doğrulandıktan sonra ayrıştırılması sırasında bir arabellek taşmasının tetiklenmesine izin verir. Bunun nedeni, sertifikaları kontrol ederken Punycode’un nasıl işlendiğidir.

Bir saldırgan, yığında saldırgan tarafından kontrol edilen dört baytı aşmak için kötü amaçlı bir e-posta adresini başarıyla oluşturabilirse, bu durumdan yararlanılabilir; bu nedenle, bir saldırganın başarılı bir saldırı gerçekleştirmek için güvenilir bir sertifikaya erişimi olmalıdır. Başarıyla kullanıldığında, hizmet reddine ve potansiyel olarak uzaktan kod yürütmeye (RCE) neden olan bir çökmeye neden olabilir.

CVE-2022-3786, bir saldırganın yalnızca nokta karakterini içeren rastgele sayıda baytı aşmak için kötü amaçlı bir e-posta adresi oluşturarak bundan yararlanabilmesi bakımından biraz farklıdır. Başarıyla kullanıldığında, hizmet reddine neden olan bir çökmeye neden olabilir.

Yazılım güvenlik açığı düzeltme uzmanı olan Rezilion’da güvenlik açığı araştırması direktörü Yotam Perkal şunları söyledi: “Tüm faktörler dikkate alındığında, bu güvenlik açıklarının vahşi doğada kod yürütülmesini sağlamak için kullanılması pek olası değil. Bununla birlikte, istismar mümkündür ve bu nedenle savunmasız varlıkları mümkün olan en kısa sürede belirlemeniz ve düzeltmeniz önerilir.”

Rapid7 araştırma direktörü Tod Beardsley şunları ekledi: “Bu OpenSSL güvenlik açığı açıklamaları ve düzeltmeleri, neyse ki, tüm spekülasyonların bizi inandıracağı kadar kötü değil.

“Satıcılar ve operatörler, mümkün olduğunda, normal değişiklik kontrol prosedürlerine uyarak ve bu kuruluşlar için özel risk profilini dikkate alarak OpenSSL’ye bağımlılıklarını 3.0.7’ye güncellemelidir. Çoğu insan için bu aslında hepimizin beklediği acil durum değil.”

Beardsley, güncellemeyi hızlı izlemesi gerekenlerin büyük olasılıkla karşılıklı kimlik doğrulama için yapılandırılmış OpenSSL uygulamalarını çalıştıranlar olacağını açıkladı – burada hem istemci hem de sunucu, kimlik doğrulama için OpenSSL tarafından sağlanan sertifikalar sağlıyor.

Cycode baş güvenlik araştırmacısı Alex Ilgayev, sürüm düşürmeye rağmen, bu güvenlik açıklarını kritik olarak ele alması gereken birçok kuruluş olacağını söyledi. “OpenSSL, sürüm düşürmenin bir nedeni olarak modern yazılımlarda yığın taşması korumalarının kullanımını gösteriyor. Ancak ATM’leri, yardımcı programları ve diğer kritik altyapıları çalıştıranlar gibi birçok kritik uygulama modern değil” dedi.

Ilgayev, sonuçta, güvenlik uzmanları için bu olaydan en büyük çıkarımın, kapsamlı ve bakımlı yazılım malzeme listesi (SBOM’ler) tutma ihtiyacı olduğunu açıkladı. “OpenSSL 3.0.7 yaması, OpenSSL’nin her yerde bulunması nedeniyle bu noktaların her ikisini de gösteriyor” dedi.

“SBOM’ları olmayan kuruluşlar, geçen haftaki duyurudan bu yana savunmasız OpenSSL kullanımını belirlemek için çabalıyor. Bu, çoğu kuruluşun çözmek için donanımlı olacağı bir önceliklendirme sorunudur. Ancak, hemen acil olmayan herhangi bir şeye öncelik vermek için işlevler arası satın alma, çoğu uygulama güvenlik ekibi için bir zorluk olmaya devam ediyor.”

Ancak güvenlik uzmanları, OpenSSL’nin her yerde bulunması, yalnızca bir uygulamanın kaynak kodunda değil, aynı zamanda onu oluşturmak ve sunmak için kullanılan altyapıda da yaygın olarak kullanıldığı anlamına geldiğinden, bir boru hattı malzeme listesi (PBOM) yaklaşımını dikkate almak için SBOM’lerin ötesine geçmeyi düşüneceklerdir, dedi. Ilgayev.

PBOM’ler, SBOM konseptini, bağımlılıkların günümüzde nasıl kullanıldığını daha iyi yansıtacak şekilde genişletir, uygulamanın kendisinde olmasa bile bir ihlale yol açabilecek üçüncü taraf kodunu ve bağımlılıkların çalışma zamanı ortamlarında gerçekte nerede dağıtıldığını hesaba katar.

Yakın tarihin Heartbleed, Struts, Jackson-databind, LodDash Log4Shell, Log4Text ve benzeri gibi, SBOM’larımızda ve PBOM’larımızda delikler açmak ve zayıflıkları bulmak için bu alıştırmayı ciddiye almalıyız. “dedi İlgayev.

Read Previous

Birleşik Krallık’taki orta ölçekli firmalarda işbirliğini ilerletmek ve durgunluğu savuşturmak için teknoloji

Read Next

İngiltere, Ukrayna için gizli siber pakete 6,4 milyon sterlin harcadı

Leave a Reply

E-posta hesabınız yayımlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir

organik hit - iş fikirleri -