Hafta sonu için her şey hazır mı? Çok hızlı değil. Dün, BleepingBilgisayar özetlenmiş şimdiye kadar bilinen tüm log4j ve logback CVE’leri.
Geçen hafta kritik log4j sıfır gün efsanesi başladığından beri, güvenlik uzmanları en güvenli sürüm olarak tekrar tekrar 2.16 sürümünü önerdiler.
Bu, log4j 2.16’yı etkileyen görünüşte önemsiz, ancak önem derecesi “Yüksek” Hizmet Reddi (DoS) güvenlik açığını düzelten 2.17.0 sürümüyle bugün değişiyor.
Ve evet, bu DoS hatası başka bir tanımlayıcıyla birlikte gelir: CVE-2021-45105.
Sonsuz özyineleme, sonlu sürümler?
Apache’nin JIRA projesinde log4j 2.16.0’ı etkileyen bir DoS hatası şüphesi ortaya çıktı. üç gün önce2.15.0’dan kısa bir süre sonra, küçük bir DoS güvenlik açığına (CVE-2021-45046) karşı savunmasız olduğu bulundu.
Dün BleepingComputer tarafından bildirildiği üzere, CVE-2021-45046’nın önem derecesi, daha yeni baypaslara izin verildikten sonra Apache tarafından Düşük (3.7) değerinden Kritik (9.0) değerine yükseltildi. veri hırsızlığı olasılığı bu istismar yoluyla.
“Aşağıdaki dizede herhangi bir nedenle bir dize değiştirme girişiminde bulunulursa, sonsuz bir özyinelemeyi tetikler ve uygulama çöker”, JIRA sorununu PoC yüküyle belirtin:
${${::-${::-$${::-j}}}}
Birkaç saat önce, güvenlik araştırmacıları dahil vx-yeraltı ve Hacker Fantastik log4j sürüm 2.16’yı da etkileyen olası bir Hizmet Reddi kusuru hakkında tweet attı:
Gelenek olduğu gibi Cuma günü yeni istismar: Araştırmacılar, Log4J 2.16 sürümünün “${${::-${::-$${::-j}}}}” yoluyla DoS’a karşı savunmasız olduğunu keşfettiler.
Daha fazla bilgi: https://t.co/pzeWiQEa68
— vx-yeraltı (@vxunderground) 17 Aralık 2021
Son üç gün boyunca konuyu tartıştıktan sonra, Apache yeni bir CVE atadı ve yeni bir sürüm yayınladı.
log4j 2.17.0 bugün çıktı, DoS’u düzeltir
olarak izlendi CVE-2021-45105ve CVSS ölçeğinde ‘Yüksek’ (7.5) puan aldıysa, log4j 2.16’daki DoS kusuru, Log4j2’nin “arama değerlendirmesinde her zaman sonsuz özyinelemeden korumadığı” için mevcuttur.
JNDI aramaları Log4j 2.16’da tamamen devre dışı bırakılmış olsa da, belirli koşullar altında öz referanslı aramalar bir olasılık olarak kaldı.
Sürümün BleepingComputer tarafından görülen sürüm notlarını “Apache Log4j2 2.0-alpha1’den 2.16.0’a kadar olan sürümler, kendine referanslı aramalardan kaynaklanan kontrolsüz özyinelemeye karşı koruma sağlamadı”.
“Günlük yapılandırması, Bağlam Araması ile varsayılan olmayan bir Model Düzeni kullandığında (örneğin, “${dolar}${dolar}{ctx:loginId}“), İş parçacığı Bağlam Haritası (MDC) giriş verileri üzerinde denetimi olan saldırganlar, özyinelemeli bir arama içeren kötü amaçlı giriş verileri oluşturabilir ve bu da StackOverflowError süreci sonlandıracaktır.”
Güvenlik açığını gidermek için log4j sürüm 2.17.0 (Java 8 için) bugün yayınlandı ve yalnızca “konfigürasyondaki arama dizelerinin” özyinelemeli olarak genişlemesine izin verir. Başka herhangi bir kullanımda, yalnızca üst düzey arama çözülür ve iç içe aramalar çözülmez.
Sürümün en büyük Java paket deposuna ulaşması bekleniyor, Maven Merkez bugün daha sonra.
Apache şu ana kadar yaklaşan 2.17.0 sürümünün ayrıntılarını resmi olarak yayınlamış olsa da, BleepingComputer tarafından görülen GitHub taahhütleri, 2.12.x dal sürümlerinde olanlar için de bir 2.12.3 sürümünün yolda olabileceğini gösteriyor.
Google: 35.000’den fazla Java paketinde Log4j kusurları var
Geliştirme, Google’ın 35.000’den fazla Java paketinin log4j güvenlik açıkları içerdiğini ortaya çıkaran analiziyle aynı zamana denk geliyor.
“Maven Central deposunun (en önemli Java paketi deposu) %8’inden fazlasını oluşturan 35.000’den fazla Java paketi, yakın zamanda açıklanan log4j güvenlik açıklarından etkilenmiştir,” diye açıklıyor Google’ın Açık Kaynak Öngörüleri Ekibinden James Wetter ve Nicky Ringland dünkü Blog yazısı.
Google’a göre, Maven Central’daki savunmasız Java paketlerinin büyük çoğunluğu log4j’yi “dolaylı” olarak ödünç alır – yani log4j, paket tarafından kullanılan bir bağımlılığa bağımlıdır, aynı zamanda şu şekilde de adlandırılan bir kavramdır: geçişli bağımlılıklar.
Google tarafından tanımlanan 35.863 paketten yaklaşık 7.000’i doğrudan log4j ödünç alındı, bu da tüm geliştiricilerin yazılımlarında yeterli görünürlüğe sahip olmayabileceğini gösteriyor:
Google, “Kullanıcının bağımlılıklarına ve geçişli bağımlılıklarına ilişkin görünürlük eksikliği, yamayı zorlaştırdı; ayrıca bu güvenlik açığının tam patlama yarıçapını belirlemeyi de zorlaştırdı” diye açıklıyor.
Maven paketlerini etkileyen, kamuya açıklanmış kritik güvenlik açıklarının geçmişine ve bu paketlerin %48’inden daha azının bunlar için bir düzeltmeye sahip olduğu gerçeğine bakıldığında, Google araştırmacıları log4j kusurlarının tüm Java paketlerinden tamamen ortadan kaldırılması için “muhtemelen yıllarca uzun bir bekleme” bekliyorlar. .
BleepingComputer tarafından bildirildiği üzere, tehdit aktörleri, log4j istismarlarıyla savunmasız sunucuları hedef alıyor. kötü amaçlı yazılımları itin, Conti fidye yazılımı çetesi özellikle savunmasız VMWare vCenter sunucuları.
Bu nedenle, kuruluşlar en son log4j sürümlerine yükseltme yapmalı ve güncellemeler için Apache’nin tavsiyelerini izlemeye devam etmelidir.