.jpg)
Eski bir GitHub çalışanı, Düğüm Paket Yöneticisi’ndeki (npm) bir zayıflığın, herkesin paketleri içindeki kötü amaçlı bağımlılıkları ve komut dosyalarını gizlemesine izin verebileceğini iddia ediyor.
Npm, GitHub’a aittir ve 17 milyondan fazla geliştiriciye hizmet veren JavaScript kod paylaşımı için kullanılır. Web sitesine göre, 2 milyondan fazla paket içeren dünyanın en büyük yazılım kaydıdır.
27 Haziran’daki blog gönderisinde, npm’nin komut satırı arayüzü ekibinin eski personel mühendisliği yöneticisi Darcy Clarke, sitedeki “açık kafa karışıklığı” adını verdiği bir zayıflığı ayrıntılarıyla açıkladı.
“Karışıklık”, npm’nin herhangi bir paketle ilişkili meta verileri doğrulamamasından kaynaklanır ve teorik olarak herhangi bir yayıncının, çalıştırdığı komut dosyaları ve dayandığı bağımlılıklar dahil olmak üzere paketleri hakkındaki belirli bilgileri gizlemesine olanak tanır.
Manifest Karışıklık Nedir?
Npm – ve buna benzer diğer depolar – son aylarda, giderek daha fazla sayıda bilgisayar korsanının paketleri zehirlemek ve kötü amaçlı yazılımlarını kod tedarik zinciri aracılığıyla yaymak için yeni yöntemler geliştirmesiyle baskı altındaydı.
Yine de tüm kredi bilgisayar korsanlarına gitmiyor – bazı npm güvenlik riskleri, yazım hatasına karşı gecikmeli çabalarında olduğu gibi platformun kendisinin çalışma şeklinden kaynaklanıyor ve şimdi, açık bir kafa karışıklığı, dedi Clarke.
Sorun şu ki, npm bir paketin “manifest” (kullanıcıların sitede bir paketi ziyaret ettiklerinde ilk gördükleri şey) ile içeriğini açıklayan standart dosya package.json arasında otomatik olarak çapraz referans oluşturmaz. Hem bildirim hem de package.json, paketin hangi betikler ve bağımlılıklar üzerinde çalıştığı gibi meta verileri içerir.
O halde, birbirleriyle aynı fikirde olmaları mantıklıdır, ancak bir yayıncı bir paketin bildirimini basitçe manipüle edebilir ve npm bunu fark etmez. Buna bir örnek olarak Clarke, package.json dosyasındaki bağımlılıkların tüm kanıtlarından arındırılmış bir manifesto ile bir npm paketi yarattı.
Teorik olarak, bilgisayar korsanları, farkında olmayan yazılım geliştiricilerden kötü amaçlı yazılımın varlığını gizlemek için aynı şeyi kendi paketleriyle yapabilirler.
Npm Neden Doğrulanmıyor?
Clarke, bariz bir kafa karışıklığı için tarihsel bir emsal öne sürdü. “Düğüm ekosistemi bugünkü haline gelmeden önce,” diye yazdı, “kullanmak ve indirmek için güvendiğiniz yazılım külliyatına katkıda bulunan insan sayısı çok azdı. Daha küçük bir toplulukla daha fazla güvenirsiniz ve hatta npm kaydı geliştiriliyordu, çoğu özellik açık kaynaktı ve katkıda bulunmak ve kod denetlemek için ücretsiz olarak mevcuttu.”
Bugün bile, “docs.npmjs.com’daki çeşitli referanslar [point] kayıt defterinin package.json içeriğini meta veri olarak sakladığı gerçeğine ve hiçbir yerde tutarlılığın sağlanmasından müşterinin sorumlu olduğundan bahsetmiyor,” diye açıkladı Clarke.
Sistemin tam olarak neden bu şekilde çalıştığı net değil. Yayınlandığı sırada GitHub, Dark Reading’in yorum talebine yanıt vermemişti.
“[Who knows] Vulcan Cyber’de kıdemli teknik mühendis olan Mike Parkin, doğrulamayı istemci tarafında sunucu tarafına karşı gerçekleştirmeyi seçmelerinin gerçek nedenleri hakkında şunları söylüyor: “Görünüşe göre daha fazla güvenlik sağlayacak ama daha fazla güvenlik sağlayacak bir yola karşı daha kolay organik büyümeye yönelmeyi seçtiler. kullanım kolaylığını etkiledi.”
Belirti Yok Karışıklık Yakında Düzeltilecek
Clarke’a göre GitHub, geçen yıl en az 4 Kasım’dan beri bariz kafa karışıklığı zayıflığının farkındaydı ve Clarke 9 Mart’ta bununla ilgili bir rapor sundu. ‘ 21 Mart’ta” paylaşımında ağıt yaktı. “Bildiğim kadarıyla, önemli bir ilerleme kaydetmediler ve bu konuyu kamuoyuna açıklamadılar.”
Ancak “GitHub anlaşılır bir şekilde zor durumda,” diye kabul etti. “npmjs.com’un on yılı aşkın bir süredir bu şekilde işlemesi, mevcut durumun büyük ölçüde kodlanmış olduğu anlamına geliyor.”
Clarke, JavaScript paketleri için alternatif bir web sitesi olan vlt’nin kurucusudur.
Görünürde bir çözüm olmadığından, bir pakette olduğunun farkına varmadıkları hiçbir şeyi indirmediklerinden emin olmak geliştiricilerin görevi olacaktır. Clarke, geliştiricilerin herhangi bir potansiyel tutarsızlığı hesaba katmak için yalnızca paketin manifestosuna değil içeriği tarafından belirtilen meta verilere güvenmelerini tavsiye etti.
Parkin’e göre, üçüncü taraf koduyla ilgilenmek, herhangi bir geliştirici ve kuruluş için zorunlu bir uygulama olmalıdır. “Bu, özellikle belirsiz kitaplıklar veya çok fazla aktif gelişme görmemiş ve yetim kalmış olabilecek daha eski olanlar veya yakın zamanda eklenen kitaplıklar için geçerlidir” diyor. “Bu faktörlerin hiçbiri, bir projede kullanılmalarını engelleyecek acil kırmızı bayraklar olmasa da, kaynakların incelenmesini daha da önemli hale getiren faktörler.”
Yine de zor olması gerekmiyor – bir süredir pek çok satıcı bu sorun üzerinde çalışıyor.
Parkin, OWASP’nin kaynak kodu analiz araçları listesine işaret ederek, “Olağandışı özellikler ve bariz istismarlar için kodu tarayabilen otomatik araçlar var ve bu araçların geliştiricinin araç setinin bir parçası olması gerekiyor” diyor.
“Paketlerinizi doğrulamak isteğe bağlı bir adım olmamalı,” diye bitiriyor sözlerini. “Bunun yerine, üçüncü taraf kitaplıklarına dayanan herhangi bir kodlama projesine yerleştirilmelidir. Nokta.”