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. 2 milyondan fazla paket içeren dünyanın en büyük yazılım kaydıdır. web sitesine göre.
İçinde 27 Haziran tarihli blog yazısınpm’nin komut satırı arayüzü ekibinin eski personel mühendisliği yöneticisi Darcy Clarke, sitedeki bir zayıflığı ayrıntılı olarak açıkladı ve “açık kafa karışıklığı” adını verdi.
“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. Örnek olarak, Clarke ile bir npm paketi yarattı. bir manifesto bağımlılıklara dair herhangi bir kanıttan sıyrılmış package.json.
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, belirtilebilir ki, bir JavaScript paketleri için alternatif web sitesi, vlt.
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, “Olağandışı özellikler ve bariz istismarlar için kod tarayabilen otomatik araçlar var ve bu araçların geliştiricinin araç setinin bir parçası olması gerekiyor” diyor. OWASP’ın kaynak kodu analiz araçları listesi.
“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.”
