‘Tidak ada cara untuk mencegahnya’: satu-satunya package manager tempat hal seperti ini terjadi secara rutin angkat bicara

 (kevinpatel.xyz)
1 poin oleh GN⁺ 1 jam lalu | 1 komentar | Bagikan ke WhatsApp
  • Registry npm mengalami serangan rantai pasok yang membahayakan jutaan aplikasi perusahaan dan mengekspos miliaran catatan pengguna, tetapi ekosistem menerimanya seolah itu tak terhindarkan
  • Senior Frontend Engineer Mark Vance menyindir kenyataan bahwa bahkan untuk mengubah satu string menjadi huruf besar, orang bergantung pada 40 tingkat dependensi bersarang dari paket yang tidak tervalidasi
  • Ketika paket utilitas yang lama terbengkalai dibajak lalu crypto-miner disuntikkan ke build produksi di seluruh dunia, situasi itu diperlakukan seperti bencana alam
  • Ekosistem Node.js menerima remote code execution berbahaya sebagai tragedi yang tak dapat diprediksi, sementara tim DevOps sibuk mengganti kunci AWS
  • Ekosistem Go, Rust, dan Web API native menjadi kontras karena memiliki standard library yang kuat dan verifikasi kriptografis untuk mengurangi ketergantungan pada pihak ketiga

Sindiran terhadap serangan rantai pasok npm

  • Registry npm terkena serangan rantai pasok yang mengompromikan jutaan aplikasi perusahaan dan mengekspos miliaran catatan pengguna, tetapi para pengembang di ekosistem JavaScript menerimanya dengan sikap seolah “memang tidak mungkin dihindari”
  • Senior Frontend Engineer Mark Vance melihat kenyataan bahwa untuk mengubah satu string menjadi huruf besar saja orang mengandalkan pohon dependensi bersarang 40 tingkat dari paket yang tidak tervalidasi sebagai harga yang harus dibayar dalam pengembangan aplikasi web modern
  • Ketika paket utilitas yang lama terbengkalai dibajak dan crypto-miner disuntikkan ke build produksi di seluruh dunia, situasi itu diperlakukan seperti bencana alam
  • Ekosistem Node.js menerima remote code execution berbahaya sebagai tragedi yang tak dapat diprediksi, sambil mengirimkan “pikiran dan doa” kepada tim DevOps yang sibuk mengganti kunci AWS

Kontras antara ekosistem lain dan npm

  • Ekosistem Go, Rust, dan Web API native memiliki standard library yang kuat sehingga sangat mengurangi ketergantungan pada kode pihak ketiga, dan menyertakan verifikasi kriptografis yang ketat dalam toolchain inti
  • Di ekosistem tersebut, kontrasnya digambarkan sebagai “hari ini jumlah kasus proyek akhir pekan buatan mahasiswa dropout yang merusak infrastruktur logistik global adalah 0”
  • Juru bicara npm menegaskan bahwa di dunia tempat pelaku jahat memang ada, hal seperti ini harus diterima, dan tidak ada kebijakan registry atau guardrail sandbox build yang bisa mencegahnya
  • Registry npm digambarkan sebagai registry open source yang secara default menjalankan install script sewenang-wenang di mesin lokal, sehingga pernyataan juru bicara itu bertemu langsung dengan risiko strukturalnya
  • Di bagian akhir, tulisan itu menyampaikan simpati kepada para korban sambil menutup dengan nada bahwa mereka harus tetap tangguh sampai “pelanggaran tak terelakkan berikutnya besok pagi”

Bacaan terkait

1 komentar

 
GN⁺ 1 jam lalu
Komentar Hacker News

  • Orang bisa punya pendapat masing-masing soal cooldown, tetapi banyak serangan rantai pasok npm belakangan ini, termasuk axios dan tanstack, kemungkinan besar bisa dihindari dengan cooldown
    Jika memakai Artifactory / Nexus, kemungkinan besar cooldown sudah ada, dan kalau belum pun pengaturannya mudah
    Karena sebagian besar kompromi npm atau PyPI diturunkan dalam hitungan jam, maksud cooldown adalah “abaikan paket yang dirilis kurang dari N hari yang lalu”. Bahkan 1 hari pun efektif, 3 hari cukup baik, dan 7 hari agak berlebihan tetapi tetap berfungsi
    Untuk cara mengaturnya, bisa memakai pnpm terbaru yang sudah memiliki cooldown bawaan 1 hari https://pnpm.io/supply-chain-security, atau kalau ingin memperbaiki semuanya sekaligus, bisa memakai https://depsguard.com yang menambahkan cooldown dan pengaturan yang direkomendasikan ke npm, pnpm, yarn, bun, uv, dan dependabot. Saya adalah maintainer-nya
    Atau ada juga https://cooldowns.dev yang lebih berfokus pada cooldown, serta skrip untuk membantu pengaturan lokal. Semuanya open source atau gratis
    Kalau Anda sudah bisa mengedit ~/.npmrc dan sejenisnya secara manual, ini mungkin tidak perlu, tetapi bagi orang-orang di sekitar Anda yang membutuhkan solusi sekali klik, ini kemungkinan besar bisa membantu mereka menghindari serangan berikutnya
    Tentu saja, saat harus menambal CVE kritis yang baru, cooldown perlu dilewati, dan masing-masing punya caranya. Tidak ada angka pastinya, tetapi dalam beberapa minggu terakhir tampaknya risiko yang lebih besar datang dari serangan rantai pasok perangkat lunak daripada CVE zero-day baru

    • Menurut saya aneh justru kalau menganggap 7 hari itu berlebihan. Kalau tidak benar-benar butuh fitur baru tertentu, bahkan saat memulai proyek baru pun versi dependensi dari beberapa bulan lalu biasanya sudah cukup
      Hal yang sama berlaku untuk upgrade dependensi berkala. Memang ada kasus yang harus segera dinaikkan, seperti respons terhadap kerentanan, tetapi saat itu saya rasa tidak masalah jika developer harus secara eksplisit menentukan versi baru yang diinginkan
    • Bukankah itu hanya menggeser masalah 7 hari ke belakang? Setahu saya, insiden seperti ini berakhir ketika seseorang terinfeksi lalu menyadarinya, bukan karena ada pasukan yang mengaudit perubahan dan menangkapnya
      Kalau semua orang memasang cooldown 7 hari, bukankah ledakannya cuma jadi terlambat?
    • Sepertinya ada kalimat yang terlewat:

      Penafian: Saya maintainer depsguard

    • Saya tidak yakin cooldown akan efektif. Seseorang tetap harus melewati cooldown, menginstal rilis yang berpotensi bermasalah, lalu menemukan masalahnya. Jika tidak ada yang melakukan itu, ya hanya menunda masalah 3/7/10/14 hari saja
      Setelah dipikir-pikir lagi sambil menulis ini, saya tetap setuju dengan cooldown 10 hari untuk tidak memasang apa pun yang dirilis dalam 10 hari terakhir. Hanya saja, menurut saya ini tidak boleh dianggap sebagai satu-satunya mitigasi
    • Kenapa tidak membuat distro atau kanal terpisah seperti distribusi Linux: latest/stable/LTS?

  • Saya penasaran apa yang sebenarnya dijamin Go atau Rust dibanding Python/npm. Bisa jadi Python/npm hanya target yang lebih menggiurkan
    Saya makin lama makin berusaha menghindari semua paket pihak ketiga

    • Cara pemberian kepemilikan paket dan namespace 100% bergantung pada pihak yang mengoperasikan package manager
      Maven Central sudah ada selama puluhan tahun, tetapi insiden pencurian namespace sangat sedikit
      Anda tidak bisa mengunggah paket dengan groupId "com.ycombinator" tanpa verifikasi bahwa Anda memiliki domain ycombinator.com. Dan begitu paket diunggah, paket itu 100% immutable meskipun berisi kode berbahaya. Tentu saja, library seperti itu akan ditandai sebagai rentan di mana-mana
      Sulit dimengerti kenapa NPM selama ini belum juga menyalin pengaman seperti Maven Central
    • Salah satu inti tulisan itu adalah bahwa sebagian besar bahasa populer lain memiliki standard library yang komprehensif. Standard library JS luar biasa kecil
      Alih-alih ada kumpulan library tepercaya yang didistribusikan bersama bahasa, aplikasi harus membuat sendiri atau mengambil dari repositori paket pihak ketiga. Karena kita terus diajari untuk menghindari NIH, orang cenderung langsung mengambil paket
      Itu sendiri belum tentu buruk, tetapi sering kali menarik kode jauh lebih banyak daripada yang diperlukan. Ekosistem JS juga menyukai modul-modul kecil, jadi butuh banyak modul, lalu semua orang menumpuk lagi di atasnya sehingga graf dependensinya menjadi sangat besar. Entah disengaja atau tidak, permukaan untuk timbulnya masalah jadi terlalu luas
      Bahasa lain menyediakan jauh lebih banyak hal secara bawaan. Bukan berarti tidak pernah ada bug dan isu keamanan, tetapi dibanding yang terlihat di ekosistem JS, itu hanya setetes air di lautan. Graf dependensi eksternal jauh lebih kecil dan fungsi inti datang dari pihak ketiga yang tepercaya
    • Penyerang pergi ke tempat korbannya berada. Frontend hampir seperti monokultur karena mayoritas memakai NPM, sementara backend tidak separah itu
      Ini bukan pembelaan untuk NPM, malah hanya menambah satu faktor yang merugikan NPM
      Bisa juga dibilang serangan seperti ini makin memperjelas perbedaan antara developer frontend dan backend, tetapi saya tidak akan melangkah sejauh itu
    • Sejujurnya, Rust juga punya pola serangan rantai pasok yang persis sama. Hanya saja ia lebih baru dan saat ini dikelola lebih baik. Tunggu saja 10 tahun lagi
    • Terakhir saya cek, npm punya autentikasi dua faktor untuk publikasi, tetapi cargo tidak. Saya tidak merasa cargo lebih baik daripada npm, hanya saja belum menjadi target yang sama menariknya

  • Di beberapa tempat kerja, saya pernah repot memasang pengaturan npm global yang aman di semua mesin developer, meminta orang agar tidak mematikannya, dan memverifikasinya lewat alat MDM
    Pengaturan bawaan yang lebih aman seharusnya sudah ada sejak lama

    • Ya jangan pakai npm. Pakai package manager yang secara bawaan tidak menjalankan postinstall, dan perpindahannya luar biasa mudah
    • Saya penasaran apa yang dimaksud pengaturan aman. Kalau maksudnya memaksakan masa cooldown atau daftar paket yang diizinkan/diblokir, pendekatan yang benar adalah perusahaan menyiapkan repositori yang mereka kendalikan untuk mengambil dari repositori npm hulu sambil menerapkan kebijakan yang diinginkan

  • Tidak ada alasan yang benar-benar sah mengapa skrip postinstall harus ada. Tim npm sekarang sudah cukup matang untuk menyatakan, “mulai npm versi sekian, skrip postinstall hanya akan dijalankan untuk versi paket yang dipublikasikan sebelum ${today}”

    • Baru-baru ini saya mengaudit beberapa skrip postinstall dari paket populer. Kebanyakan isinya memakai atau mengunduh binary native, mendeteksi kompatibilitas platform, menghubungkan secara manual alih-alih membiarkan Node melakukan bootstrap, dan mengakali masalah pada versi npm lama
      Ini karena toolchain developer seperti esbuild dibuat dalam bahasa terkompilasi dan didistribusikan sebagai binary lewat repositori npm. Kalau Anda memakai Node/npm terbaru serta OS/platform modern yang umum, seharusnya semua skrip postinstall bisa dinonaktifkan tanpa masalah yang sah
    • Skrip instalasi, seperti penandatanganan paket, adalah pengalih perhatian. Menambah atau menghapus fitur seperti itu tidak banyak memengaruhi kemungkinan ekosistem paket ini menjadi seperti worm
      Hampir tanpa pengecualian, kode npm yang dipasang pada akhirnya akan dijalankan
    • Fakta bahwa paket Rust bisa dijalankan tanpa sandbox saat build juga tidak terlalu bisa dibenarkan
    • Ini tidak benar-benar memperbaiki masalah. Kode paket juga dijalankan saat proses build dan selama pengujian. Mungkin bisa sedikit mengurangi ruang lingkup, tetapi hanya itu
    • Kalau boleh dibilang hati-hati, skrip postinstall hampir merupakan isu semu. Orang terkejut karena kode yang dikendalikan orang lain bisa dijalankan di komputer mereka dan melakukan hal buruk, dan ya, itu memang bisa terjadi
      Tetapi hal yang sama juga berlaku untuk kode biasa di dalam paket itu. Memang tidak dijalankan pada saat instalasi, tetapi pada akhirnya sesuatu di dalamnya akan dijalankan. Kalau tidak, sejak awal tidak akan dimasukkan sebagai dependensi
      Mengira bahwa menghapus skrip postinstall akan memberi dampak lebih dari sesaat terhadap tingkat penyalahgunaan adalah tanda bahwa masalah ini belum dipikirkan sampai tuntas. Sayangnya, masalah ini jauh lebih bernuansa daripada yang disiratkan tulisan aslinya
      Ini bukan soal seperti “jangan taruh tombol yang membuat sayap pesawat lepas di sebelah sakelar lampu”, melainkan inti persoalannya adalah tidak ada cara, tanpa kerja manual yang sangat melelahkan, untuk membedakan antara “kode buruk orang lain yang berjalan di komputer saya” dan “kode baik orang lain yang berjalan di komputer saya”. Dan justru untuk menghindari kerja manual yang melelahkan itulah kita menjalankan kode orang lain

  • Semua proyek Node.js dimulai dengan npm install, lalu tiba-tiba muncul 500 paket yang bahkan tidak diinginkan. Separuhnya sudah bertahun-tahun tidak disentuh

  • Ada masalah budaya yang ingin selalu menaikkan bahkan hal-hal yang sebenarnya sudah berjalan baik ke paket paling baru sebisa mungkin. Kadang changelog pun tidak dibaca untuk melihat apakah perubahan itu memang relevan
    Cooldown hanyalah cara memaksa maintainer punya sedikit kesabaran, dan itu memang efektif

    • Jika ada persyaratan kepatuhan, Anda harus meng-update karena kerentanan CVE yang menumpuk pada versi lama. Sebagian besar hampir seperti keributan palsu semacam “regex DoS”, tetapi prosedurnya tetap harus dipenuhi, jadi ya tetap harus update
    • Lalu ada juga kasus pemilik paket memperbarui sesuatu yang sebenarnya tidak perlu diperbarui agar tidak terlihat tua dan terbengkalai
      Paket Lisp bisa dipakai baik-baik saja selama 15 tahun tanpa perubahan, tetapi paket JS diperlakukan seolah-olah tidak dipelihara berarti masalah besar. Meski sebenarnya sudah selesai sejak 15 tahun lalu, orang tetap menaikkan versinya tanpa menambah apa pun, atau kadang malah memasukkan perubahan yang merusak, agar terlihat seperti masih dikelola di npm dan GitHub. Lalu semuanya ikut ter-update

  • Cooldown 7 hari terasa seperti tambalan sementara yang bisa dipasang dengan sedikit usaha. Solusi yang sesungguhnya mungkin adalah build yang reproducible dan attestasi yang ditandatangani, tetapi kebanyakan tim tampaknya tidak akan membayar biayanya sampai mereka sendiri menjadi korban

  • Ini terasa seperti artikel Onion

    warga ekosistem Node.js berdiri bersatu dalam keyakinan bahwa eksekusi kode jarak jauh berbahaya itu adalah tragedi yang sama sekali tak terduga
    Apa benar ada orang yang percaya klaim itu? Sudah terlalu banyak contoh kebalikannya
    Ini satire yang tepat sasaran terhadap kegagalan ekosistem, tetapi pada akhirnya tetap hiburan saja. Mungkin juga bisa menjadi kesempatan bagi para pemasar untuk memamerkan barang mereka. Misalnya maintainer depsguard yang sempat menghapus fakta itu dari tulisannya sendiri, lalu menambahkannya lagi, lalu menghapusnya lagi. Pada saat saya menulis ini, tulisan itu ada di posisi teratas

  • Tautan ini adalah versi yang jelas-jelas dicuci lewat AI dari lelucon lama Xe Iaso. Disayangkan
    https://xeiaso.net/shitposts/no-way-to-prevent-this/CVE-2024...
    https://news.ycombinator.com/item?id=40438408