Popüler açık kaynaklı proje ‘ip’nin GitHub deposu yakın zamanda geliştiricisi tarafından arşivlendi, yani “salt okunur” hale getirildi.
Fedor Indutny, projesine karşı hazırlanan bir CVE raporu nedeniyle internette insanlar tarafından takip edilmeye ve bu güvenlik açığına dikkat çekmeye başladı.
Ne yazık ki, Indutny’nin durumu münferit değil. Son zamanlarda, açık kaynak geliştiricileri, projeleri için onay alınmadan dosyalanan tartışmalı veya bazı durumlarda tamamen sahte CVE raporları almada bir artışla karşılaştılar.
Bu durum, bu projelerin kullanıcıları arasında yersiz paniğe yol açabiliyor ve güvenlik tarayıcıları tarafından üretilen uyarılar, geliştiriciler için baş ağrısına dönüşebiliyor.
‘node-ip’ GitHub deposu arşivlendi
Bu ayın başlarında, ‘node-ip’ projesinin yazarı olan Fedor Indutny, projenin GitHub deposunu arşivleyerek salt okunur hale getirdi ve insanların projeye yeni konular (tartışmalar) açmasını, istek göndermesini veya yorum göndermesini kısıtladı.
‘Node-ip’ projesi, npmjs.com kayıt defterinde haftalık 17 milyon indirme sayısına ulaşan ‘ip’ paketi olarak bulunmaktadır ve bu da onu JavaScript geliştiricileri tarafından kullanılan en popüler IP adresi ayrıştırma yardımcı programlarından biri haline getirmektedir.
Indutny, 25 Haziran Salı günü sosyal medyada ‘node-ip’ arşivlemesinin ardındaki gerekçelerini dile getirdi:
“Bir şey var [sic] geliştirici, Mastodon hesabı aracılığıyla şunları paylaştı: “Son birkaç aydır beni rahatsız etti ve GitHub’da node-ip deposunu arşivlememe neden oldu.”
Bunun, bu yılın başlarında projede açıklanan bir güvenlik açığı olan CVE-2023-42282 ile ilgisi var.
Geliştirici aynı gönderide “Birisi npm paketim hakkında şüpheli bir CVE başvurusunda bulundu ve ardından ‘npm denetimi’nden uyarı alan tüm insanlardan mesajlar almaya başladım” diyor.
Uygulamalarındaki npm paketleri ve bağımlılıklar gibi diğer açık projeleri kullanan Node.js geliştiricileri, uygulamaları tarafından kullanılan bu projelerden herhangi birinde kendilerine karşı güvenlik açığı rapor edilip edilmediğini kontrol etmek için “npm denetimi” komutunu çalıştırabilir.
CVE, yardımcı programın kendisine onaltılık gibi standart olmayan bir biçimde sağlanan özel IP adreslerini doğru şekilde tanımlamamasıyla ilgilidir. Bu, ‘node-ip’ yardımcı programının ” 0x7F.1…” (127.1…’i temsil eden) gibi özel bir IP adresini (onaltılık formatta) genel olarak ele almasına neden olur.
Bir uygulamanın, sağlanan IP adresinin genel olup olmadığını kontrol etmek için yalnızca node-ip’e güvenmesi durumunda, standart olmayan girişler, yardımcı programın etkilenen sürümleri tarafından tutarsız sonuçlar döndürülmesine neden olabilir.
‘Şüpheli’ güvenlik etkisi
Kamu kaynakları, CVE-2023-42282’nin başlangıçta 9,8 veya “kritik” olarak derecelendirildiğini öne sürüyor.
Her ne kadar Indutny sorunu projesinin sonraki sürümlerinde çözmüş olsa da, hatanın bir sorun teşkil ettiğine karşı çıktı. gerçek güvenlik açığı ve bu da yüksek şiddette.
Geliştirici daha önce GitHub’dan CVE’yi iptal etmesini talep ederek, “Hatanın güvenlik üzerindeki etkisinin oldukça şüpheli olduğunu düşünüyorum” yazmıştı.
“Modülün güvenlikle ilgili herhangi bir kontrol için kullanılmasını gerçekten planlamamış olsam da, güvenilmeyen bir girdinin nasıl bir ortama aktarılabileceğini çok merak ediyorum. ip.isPrivate veya ip.isPubliC [functions] ve daha sonra ağ bağlantısının nereden geldiğini doğrulamak için kullanılır.”
GitHub güvenlik ekibinin bir üyesinin açıkladığı gibi, bir CVE’ye itiraz etmek de basit bir iş değildir. Bir proje bakıcısının, başlangıçta CVE’yi yayınlayan CVE Numaralandırma Yetkililerini (CNA) takip etmesi gerekir.
CNA’lar geleneksel olarak NIST’in NVD ve MITRE’sini içeriyordu. Son birkaç yıldır, teknoloji şirketleri ve güvenlik satıcıları da listeye katıldı ve istedikleri zaman CVE’ler yayınlayabiliyorlar.
Bu CVE’ler, güvenlik açığı açıklaması ve bildirilen önem derecesiyle birlikte GitHub önerileri gibi diğer güvenlik veritabanları tarafından dağıtılır ve yeniden yayınlanır.
Indutny’nin sosyal medyadaki gönderisinin ardından GitHub, veri tabanlarındaki CVE’nin ciddiyetini düşürdü ve geliştiriciye, gelen raporları daha iyi yönetmek ve gürültüyü azaltmak için özel güvenlik açığı raporlamasını açmasını önerdi.
Bu yazının yazıldığı sırada, güvenlik açığının NVD üzerindeki ciddiyeti hâlâ “kritik” düzeydedir.
Büyüyen bir sıkıntı
Başlangıçta güvenlik araştırmacılarının bir projedeki güvenlik açıklarını etik bir şekilde raporlamalarına ve sorumlu bir şekilde ifşa ettikten sonra bunları kataloglamalarına yardımcı olmak için tasarlanan CVE sistemi, son zamanlarda doğrulanmamış raporlar sunan bir grup topluluğun ilgisini çekmeye başladı.
CVE’lerin birçoğu sorumlu araştırmacılar tarafından iyi niyetle dosyalanmış ve inandırıcı güvenlik açıklarını temsil ederken, son zamanlarda büyüyen bir model, yeni başlayan güvenlik meraklılarının ve hata ödülü avcılarının, gerçek dünyayı oluşturan güvenlik hatalarını bildirmek yerine, özgeçmişlerini zenginleştirmek için görünüşte CVE’leri “toplamasını” içeriyor. , sömürüden kaynaklanan pratik etki.
Sonuç olarak, geliştiriciler ve proje sahipleri geri adım attılar.
Eylül 2023’te, tanınmış yazılım projesi ‘curl’ün yaratıcısı Daniel Stenberg, projeye karşı bildirilen bir Hizmet Reddi hatası olan “sahte curl sorunu CVE-2020-19909″u kınadı.
NVD’nin geçmişine göre başlangıçta 9.8 veya kritik öneme sahip olarak derecelendirilen CVE, kusurun somut güvenlik etkisini sorgulayan tartışmaların ardından “düşük” 3.3’e düşürüldü.
Stenberg, CVE girişini eleştirerek “Bu benzersiz bir örnek değildi ve ilk kez de olmadı. Bu yıllardır devam ediyor” diye yazdı.
“Ben zaaflar etrafında felsefi düşünce egzersizlerinin hayranı değilim.”
“Bunlar gerçek meselelerden dikkat dağıtıyor ve ben onları oldukça anlamsız buluyorum. Bu kusurun çok sayıda derleyici kullanarak çok sayıda platformda nasıl işlediğini test etmek kolaydır.”
“Hiçbirinde güvenlik sorunu yok.”
Stenberg’e göre, “aptal hatanın” teknik detayları göz önüne alındığında, beklenmedik davranışlara yol açabilse de, kötüye kullanılabilecek bir güvenlik açığı değildi.
Haftalık 64 milyon indirme alan bir başka npm projesi olan micromatch’te ‘yüksek’ şiddette ReDoS güvenlik açıkları rapor edildi ve yaratıcıları, sorunları araştıran topluluk üyeleri tarafından kovalandı.
“Güvenlik açığına karşı hassas olan mikro eşleşme veya destekleri uygulayan en az bir kütüphaneye işaret edebilir misiniz, böylece bunun sadece teorik olarak değil, gerçek dünyada da nasıl bir güvenlik açığı olduğunu görebiliriz?” diye sordu Jon Schlinkert, micromatch projesi için başvuran CVE-2024-4067’ye tepki göstererek.
Aynı başlıkta, geliştirici, güvenlik açığını bildiren kişiden tatmin edici bir kavram kanıtı alamayınca şu şekilde yanıt vermiş:
“Kendiniz yapmadığınız sürece bir güvenlik açığı bile olamayacak şeyler için her zaman bu sorunlarla karşılaşıyorum. Bir tarayıcı tarafından asla erişilemeyecek düşük seviyeli kütüphanelerdeki regex gibi, kullanıcıların yalnızca uygulamanız tarafından kullanılan bir web formunda düzenli ifadeler göndermesine izin vermediğiniz sürece.”
“Gerçek dünyadaki bir kütüphanenin bu ‘güvenlik açıklarıyla’ nasıl karşılaşacağına dair örnekler istedim ve siz hiçbir zaman bir örnekle yanıt vermediniz.”
Ben de yakın zamanda, üçüncü bir tarafın bizi projenin potansiyel bir “risk” oluşturduğu konusunda bilgilendirmesinin ardından Micromatch geliştiricilerine mesaj attım; çünkü o sırada bunun sorumlu bir davranış olduğu düşünülüyordu.
Ne yazık ki, istismar edilebilir bir güvenlik açığını temsil etmek yerine, geliştiricilerin çoktan kovalandığı bir rahatsız edici rapor (tıpkı CVE-2024-4067 gibi) haline geldi.
Proje yöneticileri için can sıkıcı bir durum olmasının yanı sıra, doğrulanmamış güvenlik açığı raporları için CVE’ler verilmesi eylemi, bir projeye, yaratıcılarına ve daha geniş tüketici tabanına karşı bir Hizmet Reddi (DoS) başlatmaya benzer ve bunun da iyi nedenleri vardır.
Uygulamalarınıza güvenlik açığı olan bileşenlerin erişmesini engellemek için tasarlanmış geliştirici güvenlik çözümleri (npm audit gibi), bilinen herhangi bir güvenlik açığı tespit edildiğinde uyarıları tetikleyebilir ve ayarlarınıza bağlı olarak yapılarınızı bozabilir.
2023’te bir yorumcu sahte CVE kıvrımına tepki göstererek “Jackson birkaç ay önce bu sorunu yaşadı; birisi projeye karşı kritik bir CVE bildirip gezegenin her yerindeki yapıları bozdu.”
Diğer geliştiricilerin belirttiği gibi, sorun projedeki bir güvenlik sorunu olmaktan ziyade, özyinelemeli Java veri yapılarının doğasında olan bir durumu temsil ediyordu.
Denge nerede?
Bunun gibi tekrarlanan olaylar şu soruyu gündeme getiriyor: Kişi nasıl denge kurabilir?
Teorik güvenlik açıklarının durmaksızın rapor edilmesi, çoğu gönüllü olan açık kaynak geliştiricilerin gürültüyü tetiklemesinden bitkin düşmesine neden olabilir.
Öte yandan, acemiler de dahil olmak üzere güvenlik uygulayıcılarının, projeyi yürütenleri rahatsız etmemek için güvenlik kusuru olduğunu düşündükleri bir şey üzerinde durması etik olur mu?
Üçüncü bir sorun, aktif bir bakımcısı olmayan projeler için ortaya çıkar. Örneğin, yıllardır dokunulmamış terk edilmiş yazılım projeleri, ifşa edilse bile asla düzeltilmeyecek güvenlik açıkları içerir ve orijinal bakımcılarıyla iletişim kurmanın hiçbir yolu yoktur.
Bu gibi durumlarda, CNA’lar ve hata ödülü platformları gibi aracılar belirsizliğe düşüyor.
Bir araştırmacıdan bir güvenlik açığı raporu alındığında, bu kuruluşlar her zaman bu tür her raporu bağımsız olarak yeterince inceleyemeyebilir. (Artık yok olan) proje bakıcılarından haber almadan, “sorumlu açıklama” penceresi geçtikten sonra CVE’leri atamak ve yayınlamak zorunda kalabilirler.
Bu sorunlara henüz basit bir cevap mevcut değil.
Güvenlik araştırma, geliştirici ve satıcı toplulukları bir araya gelip etkili bir çözüm bulana kadar, geliştiriciler sahte raporlar yüzünden hayal kırıklığına uğrayacak ve CVE sistemi kağıt üzerinde güvenilir görünse de aslında hiçbir anlamı olmayan abartılı “güvenlik açıklarıyla” dolacak.