‘Bunu engellemenin yolu yok’: Düzenli olarak bunun yaşandığı tek paket yöneticisi konuştu

 (kevinpatel.xyz)
1 puan yazan GN⁺ 1 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • npm registry tedarik zinciri saldırısıyla milyonlarca kurumsal uygulama ve milyarlarca kullanıcı kaydı açığa çıktı, ancak ekosistem bunu kaçınılmaz bir şeymiş gibi karşılıyor
  • Senior Frontend Engineer Mark Vance, bir karakter dizisini büyük harfe çevirmek için bile doğrulanmamış bir paketin 40 katmanlı iç içe bağımlılığına bel bağlanan gerçeği iğneliyor
  • Uzun süre sahipsiz kalmış bir yardımcı paket ele geçirilip dünya çapındaki production build’lere crypto-miner enjekte edilmesi, sanki doğal afetmiş gibi ele alınıyor
  • Node.js ekosistemi kötü amaçlı uzaktan kod çalıştırmayı öngörülemez bir trajedi gibi karşılıyor ve DevOps ekipleri AWS anahtarlarını döndürmekle uğraşıyor
  • Go, Rust ve yerel Web API ekosistemleri, güçlü standart kütüphaneler ve kriptografik doğrulama sayesinde üçüncü taraf bağımlılıklarını azaltan bir karşıt örnek oluşturuyor

npm tedarik zinciri saldırısı hicvi

  • npm registry üzerindeki tedarik zinciri saldırısıyla milyonlarca kurumsal uygulama ihlal edildi ve milyarlarca kullanıcı kaydı açığa çıktı, ancak JavaScript ekosistemindeki geliştiriciler bunu “tamamen kaçınılmazdı” der gibi karşılıyor
  • Senior Frontend Engineer Mark Vance, tek bir karakter dizisini büyük harfe çevirmek için doğrulanmamış bir paketin 40 katmanlı iç içe bağımlılık ağacına bel bağlanan gerçeği, modern web uygulaması geliştirmenin bedeli olarak görüyor
  • Uzun süre sahipsiz bırakılmış bir yardımcı paketin ele geçirilip dünya çapındaki production build’lere crypto-miner enjekte edilmesi, doğal afet gibi muamele görüyor
  • Node.js ekosistemi kötü amaçlı uzaktan kod çalıştırmayı öngörülemez bir trajedi gibi karşılıyor ve AWS anahtarlarını yenilemekle meşgul DevOps ekiplerine “düşünceler ve dualar” gönderiyor

Diğer ekosistemlerle npm karşılaştırması

  • Go, Rust ve yerel Web API ekosistemleri güçlü standart kütüphaneler sayesinde üçüncü taraf koda bağımlılığı büyük ölçüde azaltıyor ve temel araç zincirine sıkı kriptografik doğrulama ekliyor
  • Bu ekosistemlerde, “üniversite terk birinin hafta sonu projesinin” küresel lojistik altyapısını çökerttiği gün sayısının bugün de 0 olduğu söylenerek karşıtlık kuruluyor
  • npm sözcüsü, kötü niyetli aktörlerin var olduğu bir dünyada bunun kabul edilmesi gerektiğini ve bunu önleyebilecek herhangi bir registry politikası ya da build sandbox guardrail’i bulunmadığını açıkça söylüyor
  • npm registry, yerel makinede rastgele install script’leri varsayılan olarak çalıştıran bir açık kaynak registry olarak tasvir ediliyor; bu da sözcünün sözleriyle yapısal riski bir araya getiriyor
  • Sonunda mağdurlara teselli sunulurken, “yarın sabah yaşanacak bir sonraki kaçınılmaz ihlale” kadar dayanıklılığı korumak gerektiği vurgusuyla bitiyor

İlgili okumalar

1 yorum

 
GN⁺ 1 시간 전
Hacker News yorumları

  • Cooldown hakkında herkesin farklı bir fikri olabilir ama axios, tanstack ve diğerleri dahil son dönemdeki npm tedarik zinciri saldırılarının önemli bir kısmı cooldown ile önlenebilirdi
    Artifactory / Nexus kullanıyorsanız büyük olasılıkla zaten bir cooldown vardır; yoksa da yapılandırması kolaydır
    npm veya PyPI ihlallerinin çoğu birkaç saat içinde kaldırıldı, dolayısıyla cooldown şu anlama geliyor: “Yayınlanalı N gün olmamış paketleri yok say.” 1 gün bile işe yarar, 3 gün iyidir, 7 gün biraz abartılıdır ama çalışır
    Bunu ayarlamak için varsayılan 1 günlük cooldown içeren en güncel pnpm’i kullanabilir https://pnpm.io/supply-chain-security ya da bunu tek seferde düzeltmek için npm, pnpm, yarn, bun, uv ve dependabot’a cooldown ile önerilen ayarları ekleyen https://depsguard.com kullanabilirsiniz. Bunun bakımını ben yapıyorum
    Ya da daha çok cooldown’a odaklanan https://cooldowns.dev var; yerel ayarları yapmaya yardımcı olan script’ler de içeriyor. Hepsi açık kaynak ya da ücretsiz
    ~/.npmrc gibi dosyaları elle düzenlemeyi biliyorsanız bunlara pek gerek yok, ama çevrenizde tek tıkla çözüm isteyenler için bir sonraki saldırıdan kaçınmalarını sağlayabilir
    Elbette yeni bir kritik CVE yamasını almak zorunda olduğunuzda cooldown’ı aşmanız gerekir ve bunun her biri için yöntemler var. Elimde kesin sayılar yok ama son birkaç haftada yeni zero-day CVE’lerden çok yazılım tedarik zinciri saldırılarından risk gelmiş gibi görünüyor

    • 7 günün abartılı olduğu fikri bana daha tuhaf geliyor. Belirli bir yeni özelliğe gerçekten ihtiyaç yoksa, yeni bir projeye başlarken bile genelde birkaç ay önce çıkmış bağımlılık sürümleri yeterli olmalı
      Düzenli bağımlılık yükseltmeleri için de aynı şey geçerli. Yalnız güvenlik açığına müdahale gibi hemen geçmeniz gereken durumlar var; o zaman geliştiricinin istediği yeni sürümü açıkça belirtmesi bence sorun değil
    • Ama o zaman sorun sadece 7 gün sonraya ertelenmiş olmuyor mu? Bu tür olayların sonu genelde biri etkilenip fark ettiği için geliyor; değişiklikleri denetleyen bir ordu olduğu için değil diye düşünüyordum
      Herkes 7 günlük cooldown uygularsa olay sadece daha geç patlamış olmaz mı?
    • Sanki eksik kalan bir ifade var:

      Disclaimer: I maintain depsguard

    • Cooldown’ın etkili olacağından emin değilim. Birilerinin cooldown’ı aşıp sorunlu olabilecek sürümü kurması ve problemi fark etmesi gerekir. Kimse yapmazsa sadece sorunu 3/7/10/14 gün geciktirmiş olursunuz
      Yazarken biraz daha düşündüm de, yine de son 10 gün içinde yayınlananları kurmamayı sağlayan 10 günlük cooldown fikrine katılıyorum. Ama bunun tek hafifletme yöntemi olmasını beklememek gerekir
    • Linux dağıtımlarındaki gibi ayrı güncel/kararlı/uzun süreli destek dağıtımları ya da kanalları neden olmasın?

  • Go veya Rust’ın Python/npm’e kıyasla gerçekte neyi garanti ettiğini merak ediyorum. Belki de sadece Python/npm daha iştah açıcı bir hedef
    Giderek tüm üçüncü taraf paketlerden kaçınmaya çalışıyorum

    • Paket ve namespace sahipliğinin nasıl verileceği %100 paket yöneticisini işleten kuruma bağlı
      Maven Central onlarca yıldır var ama namespace çalınması olayları çok az
      ycombinator.com alan adını kontrol ettiğinizi doğrulamadan groupId com.ycombinator ile paket yayınlayamazsınız. Ayrıca bir kez yayımlanan paket, kötü amaçlı kod içerse bile %100 değiştirilemez. Tabii böyle kütüphaneler her yerde savunmasız olarak işaretlenir
      NPM’in bunca zamandır Maven Central benzeri güvenlik önlemlerini kopyalayamamış olması anlaşılır gibi değil
    • Yazının ana fikirlerinden biri, diğer popüler dillerin çoğunda kapsamlı bir standart kütüphane bulunması. JS’in standart kütüphanesi şaşırtıcı derecede küçük
      Dille birlikte gelen doğrulanmış bir kütüphane seti yerine, uygulamalar bunu ya kendileri yazmak ya da üçüncü taraf paket depolarından almak zorunda. İnsanlara yıllardır NIH’den kaçınmaları öğretildiği için paket almaya yöneliyorlar
      Bunun kendisi mutlaka kötü değil ama çoğu zaman ihtiyaçtan fazla kod çekiliyor. JS ekosistemi küçük modülleri de sevdiğinden çok sayıda modül gerekiyor; herkes bunun üstüne tekrar inşa edince bağımlılık grafiği devasa oluyor. Kasıtlı olsun olmasın, sorun çıkabilecek yüzey alanı çok büyük
      Diğer diller daha fazla şeyi kutudan çıktığı gibi sunuyor. Hata ve güvenlik sorunları hiç olmadı değil ama JS ekosisteminde gördüklerimizin yanında devede kulak kalıyor. Harici bağımlılık grafiği çok daha küçük ve çekirdek işlevler güvenilir üçüncü taraflardan geliyor
    • Saldırganlar kurbanın olduğu yere gider. Frontend tarafı, büyük çoğunluğun NPM kullandığı bir monokültüre yakın; backend’de bu o kadar belirgin değil
      Bu NPM için mazeret değil, aksine aleyhine bir madde daha demek
      Bunun frontend geliştiricileriyle backend geliştiricileri arasındaki farkı daha da belirginleştirdiği de söylenebilir ama o konuya girmeyeyim
    • Dürüst olmak gerekirse Rust da tam olarak aynı tedarik zinciri saldırı kalıplarına sahip. Sadece daha yeni ve şu an daha iyi yönetiliyor. Bir 10 yıl bekleyin yeter
    • En son baktığımda npm’de yayınlama için iki faktörlü kimlik doğrulama vardı, cargo’da yoktu. cargo’nun npm’den özellikle daha iyi olduğunu düşünmüyorum; sadece o kadar cazip bir hedef değil

  • Birçok iş yerinde tüm geliştirici makinelerine güvenli global npm ayarları kurmak, insanların bunu kapatmamasını istemek ve MDM araçlarıyla doğrulamak için çok uğraştım
    Daha güvenli varsayılan ayarlar çoktan gelmiş olmalıydı

    • npm kullanmayın yeter. Varsayılan olarak postinstall çalıştırmayan bir paket yöneticisi kullanın; geçiş inanılmaz derecede kolay
    • Güvenli ayardan ne kastedildiğini merak ediyorum. Cooldown süresi ya da paket izin/engelleme listelerini zorlamak istiyorsanız, doğru yaklaşım şirketin kontrol ettiği bir depo kurup üst npm deposundan çekmek ama istediğiniz politikaları uygulamak olur

  • postinstall script’lerinin var olması için meşru bir neden yok. npm ekibi artık yeterince olgunlaştı; “npm’in şu sürümünden itibaren postinstall script’leri yalnızca ${today} tarihinden önce yayınlanmış paket sürümlerinde çalıştırılacak” diyebilmeli

    • Son zamanlarda popüler paketlerin birçok postinstall script’ini denetledim. Çoğu native binary kullanıyor veya indiriyor, platform uyumluluğunu algılıyor, Node’un bootstrap etmesini beklemek yerine doğrudan bağlanıyor ve eski npm sürümlerindeki sorunları aşıyor
      Bunun nedeni esbuild gibi geliştirme araç zincirlerinin derlenen dillerle yazılması ve npm deposu üzerinden binary olarak dağıtılması. Güncel Node/npm ve yaygın güncel OS/platform kullanıyorsanız, meşru bir sorun yaşamadan tüm postinstall script’lerini devre dışı bırakabilmeniz gerekir
    • Kurulum script’leri, paket imzaları gibi, dikkati dağıtan bir unsur. Bu paket ekosisteminin solucan gibi yayılabilme potansiyeli üzerinde şu ya da bu özelliğin eklenip çıkarılmasının büyük bir etkisi yok
      Kurulu npm kodu neredeyse istisnasız şekilde çalıştırılır
    • Rust paketlerinin derlenirken sandbox olmadan çalıştırılabilmesi de pek meşru sayılmaz
    • Bu aslında sorunu çözmez. Çünkü paket kodu build sırasında ve testlerde de çalıştırılıyor. Kapsamı biraz daraltabilir ama hepsi bu
    • Dikkatli söylemek gerekirse, postinstall script’leri neredeyse tamamen sahte bir tartışma başlığı. İnsanlar, başkasının kontrol ettiği kodun kendi makinelerinde çalışıp kötü şeyler yapabilmesine şaşırıyor; evet, olabilir
      Ama paketin içindeki normal kod için de aynısı geçerli. Kurulum anında çalışmasa bile eninde sonunda içindeki bir şey çalışacak. Aksi halde zaten bağımlılık olarak eklenmezdi
      Postinstall script’lerini kaldırmanın istismar oranı üzerinde anlık etkiden fazlası olacağını düşünmek, sorunun sonuna kadar düşünülmediğinin işareti. Ne yazık ki bu mesele, asıl yazının ima ettiğinden çok daha nüanslı
      Bu, “kanatları düşüren düğmeyi ışık anahtarının yanına koymayalım” türü bir mesele değil; asıl sorun, “başkasının kötü kodunun benim bilgisayarımda çalışmasını” engellemek isterken “başkasının iyi kodunun benim bilgisayarımda çalışmasını” istememiz ve bunu çok zahmetli manuel inceleme olmadan ayırt etmenin bir yolu olmaması. Zaten başkasının kodunu çalıştırmamızın nedeni de o zahmetli manuel işi yapmaktan kaçmak

  • Bütün Node.js projeleri npm install ile başlıyor ve bir anda istemediğiniz 500 paket oluveriyor. Bunların yarısına da yıllardır dokunan yok

  • Hâlihazırda iyi çalışan şeyleri bile mümkün olduğunca en güncel paketlere yükseltmek isteme şeklinde kültürel bir sorun var. İnsanlar bazen değişiklik günlüklerini, değişikliğin kendileri için anlamlı olup olmadığını görmek için bile okumuyor
    Cooldown, bakım yapanlara biraz sabır dayatmanın bir yolu sadece ve gerçekten işe yarıyor

    • Uyumluluk gereksinimleri varsa, eski sürümlere yağan CVE açıkları yüzünden güncellemeniz gerekir. Çoğu “regex DoS” gibi neredeyse sahte şeyler olsa da, prosedürü karşılamak zorundasınızdır; o yüzden yine de güncellersiniz
    • Bir de paket sahibinin eski ve terk edilmiş görünmemek için güncellenmesine gerek olmayan şeyleri güncellemesi durumu var
      Lisp paketleri 15 yıl boyunca hiç değişmeden gayet iyi kullanılabilirken, JS paketleri bakım yapılmıyormuş gibi görünürse felaket sayılıyor. Oysa 15 yıl önce zaten bitmiş olabilir; ama npm ve GitHub’da yönetiliyormuş gibi görünmek için hiçbir şey eklemeden, hatta bazen kırıcı değişiklikler koyup sürüm artırılıyor. Sonra her şey güncelleniyor

  • 7 günlük cooldown, az emekle uygulanabilen geçici bir çözüm gibi hissettiriyor. Gerçek çözüm muhtemelen yeniden üretilebilir build’ler ve imzalı kanıtlar olurdu, ama çoğu ekip zaten başına gelmeden bunun maliyetini ödemeyecek

  • Bu bir Onion yazısı gibi okunuyor

    residents of the Node.js ecosystem stood unified in their belief that the malicious remote-code execution was a completely unpredictable tragedy
    Buna gerçekten inanan var mı? Aksini gösteren çok fazla örnek vardı
    Ekosistemin başarısızlığını iyi vuran bir hiciv ama sonuçta eğlencelik bir içerik. Belki pazarlamacılara da ürünlerini öne çıkarma fırsatı veriyordur; depsguard bakımcısının kendi yazısında bunu silip sonra geri ekleyip sonra yine silmesi gibi. Bunu yazdığım anda o yazı en üstteydi

  • Bu bağlantı, Xe Iaso’nun uzun süredir yaptığı bir esprinin açıkça AI ile cilalanmış bir versiyonu. Üzücü
    https://xeiaso.net/shitposts/no-way-to-prevent-this/CVE-2024...
    https://news.ycombinator.com/item?id=40438408