Paket npm berbahaya ditemukan di berbagai layanan Red Hat Cloud Services

 (github.com/RedHatInsights)
1 poin oleh GN⁺ 4 jam lalu | 1 komentar | Bagikan ke WhatsApp
  • Isu ini masih terbuka, dan pada saat penulisan belum ada penanggung jawab, milestone, maupun branch atau PR yang terhubung
  • Ini didaftarkan sebagai isu keamanan bahwa versi berbahaya ditemukan pada beberapa rilis npm dalam cakupan @redhat-cloud-services/
  • Sebagai referensi, disertakan artikel analisis dari StepSecurity dan hasil pencarian OSS Security Feed
  • Daftar dampak yang diperbarui mencakup 32 paket seperti @redhat-cloud-services/chrome, frontend-components, rbac-client, types, dan vulnerabilities-client
  • Versi yang terdampak dalam tabel umumnya berjumlah 3 per paket, sementara @redhat-cloud-services/vulnerabilities-client hanya mencakup dua versi: 2.1.9 dan 2.1.11
  • Berdasarkan seluruh tabel, jumlah versi yang terdampak dapat dihitung mencapai 95 versi, dan judul PR eksternal yang disebut terpisah juga merujuk pada 95 versions
  • Rangkaian @redhat-cloud-services/frontend-components-* dan beberapa paket *-client ikut tercakup, sehingga ini bukan masalah pada satu paket saja melainkan pada rilis di seluruh cakupan yang sama
  • Di komentar, pertanyaan “What are these?” dijawab dengan “all that module is pwned”, yang menunjukkan pemahaman bersama bahwa seluruh daftar telah disusupi
  • DanielRuf menuliskan bahwa ia telah menambahkan insiden ini ke supply-chain-incidents
  • Aktivitas GitHub menunjukkan ringkasan konten yang merujuk ke isu ini dan PR terkait deteksi, tetapi hingga isi saat ini, diagnosis, langkah mitigasi, penghapusan, maupun versi perbaikan dari pihak Red Hat belum disajikan

Bacaan terkait

1 komentar

 
GN⁺ 4 jam lalu
Komentar Hacker News

  • Semoga tidak masalah meminjam thread ini lagi untuk membahas pengaturan cooldown. axios, tanstack, @redhat-cloud-services, dan berbagai serangan rantai pasok npm belakangan ini kemungkinan bisa dicegah jika ada cooldown
    Jika memakai Artifactory/Nexus, kemungkinan besar ini sudah ada, dan kalau pun belum, konfigurasinya mudah. Karena sebagian besar kompromi npm atau PyPI diturunkan dalam hitungan jam, pendekatan mengabaikan paket yang dirilis kurang dari N hari sudah cukup. Bahkan 1 hari efektif, 3 hari cukup baik, dan 7 hari agak berlebihan tetapi tetap berfungsi
    pnpm terbaru kini menerapkan cooldown 1 hari secara default: https://pnpm.io/supply-chain-security
    Jika ingin semuanya selesai dengan satu klik, bisa memakai https://depsguard.com. Ini adalah CLI yang menambahkan cooldown dan pengaturan yang direkomendasikan ke npm, pnpm, yarn, bun, uv, dan dependabot, dan saya adalah maintainer-nya
    Ada juga https://cooldowns.dev yang lebih berfokus pada cooldown, serta skrip untuk membantu konfigurasi lokal. Semuanya open source/gratis
    Kalau Anda bisa mengedit ~/.npmrc dan semacamnya secara manual, ini memang tidak terlalu diperlukan, tetapi jika ada orang di sekitar Anda yang hanya butuh perbaikan satu klik, ini bisa membantu mereka menghindari serangan berikutnya
    Hanya saja, saat perlu menambal CVE kritis baru, cooldown harus bisa dilewati, dan tiap alat punya cara bypass-nya sendiri. Saya tidak punya angka pasti untuk beberapa bulan terakhir, tetapi bahkan di era penemuan kerentanan ala Mythos, risikonya tetap tampak lebih besar dari serangan rantai pasok perangkat lunak seperti penyebaran versi berbahaya daripada CVE zero-day baru

    • Sebagai pengembang embedded yang terbiasa mengunci toolchain dan dependensi selama bertahun-tahun, budaya pengembangan web terasa mengejutkan dalam banyak hal
    • Ada repo GitHub milik seorang teman yang mengumpulkan cara konfigurasi yang waras dan sedikit lebih aman: https://github.com/jordanconway/package-manager-hardening
    • Adakah cara yang masuk akal untuk menerapkan cooldown juga pada pull image Docker/Podman?
    • Walaupun saya termasuk orang yang bisa membuka file ~/.npmrc dan menambahkan satu baris, tetap terasa seperti kelompok yang sangat kecil yang benar-benar membutuhkan perbaikan satu klik
    • Selain cooldown, akan bagus jika lebih banyak package manager menangani pembaruan keamanan secara terpisah dari rilis biasa (perbaikan bug/peningkatan performa/fitur baru)
      Sangat mungkin untuk mengatakan, “pembaruan keamanan seharusnya hanya berisi pembaruan keamanan dan tidak membawa fitur lain.” Dengan begitu, peneliti keamanan maupun alat otomatis akan lebih mudah melakukan audit
      Cooldown bisa diterapkan pada rilis biasa, sementara untuk pembaruan keamanan cooldown bisa dihilangkan atau dibuat jauh lebih singkat
      Sistem seperti Debian, dengan server yang sangat stabil dan pengaturan unattended upgrades agar hanya berlaku untuk pembaruan keamanan, layak dijadikan referensi. Rilis paket baru seperti ini juga lebih mudah diaudit oleh peneliti keamanan.

  • Di setiap thread seperti ini, selalu banyak komentar yang bersikap seolah-olah jenis serangan ini hanya ada di npm, atau menyindir seakan tidak ada tindakan apa pun yang pernah diambil, tapi menurut saya itu tidak adil.
    Banyak juga komentar yang menyebut fitur-fitur bagus yang diperkenalkan delay line dan pnpm untuk melindungi konsumen paket.
    Bagian yang lebih jarang dibicarakan adalah alat di sisi maintainer paket. MFA untuk publikasi: https://docs.npmjs.com/requiring-2fa-for-package-publishing-..., dan trusted publishers yang tersedia sejak sekitar setahun lalu: https://docs.npmjs.com/trusted-publishers
    Baru-baru ini, hadir juga staged publishing yang menggabungkan keunggulan keduanya: https://docs.npmjs.com/staged-publishing
    Sekarang kita bisa melakukan publikasi dari CI tanpa kredensial statis, lalu mewajibkan maintainer menyetujui dengan MFA sebelum benar-benar dipublikasikan ke registry. Jika diinginkan, kita juga bisa mewajibkan persetujuan ganda atau jeda waktu di sisi CI dengan perlindungan GitHub Actions Environments.
    Komunitas perlu didorong untuk mengadopsi pengaman publikasi seperti ini, kalau tidak masalah ini akan terus berlanjut.

    • Menurut [1], “semua paket yang terdampak dipublikasikan dari repositori RedHatInsights/javascript-clients melalui GitHub Actions OIDC, yang menunjukkan bahwa pipeline CI/CD hulu itu sendiri telah dikompromikan”.
      Kalau begitu, paket berbahaya itu juga akan mendapat bintang hijau dan meyakinkan pengguna dengan klaim “dibangun dan ditandatangani dengan provenance”.
      [1] https://lwn.net/Articles/1075742/
    • Karena ini terus terjadi, ya memang agak lucu. Serangan npm sudah sampai level bisa ditandai di kalender, dan seseorang bahkan membuat parodi versi npm dari artikel klasik The Onion, “tidak ada cara untuk menghindarinya”.
      Bagus bahwa ada pekerjaan yang dilakukan untuk mencegahnya, tapi tetap saja terus terjadi. Lucunya dalam arti “ya ampun, kejadian lagi”.
    • Baru bisa dibilang benar-benar melakukan sesuatu kalau dibuat wajib untuk semua orang.
    • Saya tidak terlalu terkesan dengan perubahan yang sifatnya mekanis, dan sepertinya ada kelompok yang melihat masalah ini sebagai masalah budaya.
      Dari luar, pengembangan web punya energi seperti wilayah barat liar yang kacau. Ada mutabilitas, dynamic typing, standar dan framework yang terus berubah, continuous deployment, CDN, kampanye A/B real-time, banyak dependensi, dan data pengguna sensitif yang tersebar di berbagai infrastruktur.
      Saya tidak bilang sudut pandang ini pasti benar, dan juga tidak menganggap sikap “tuh kan” itu tepat, tapi saya paham dari mana asalnya.
    • Menurut saya, keduanya adalah solusi lipstik pada babi. Pada akhirnya semuanya cuma variasi dari “mari kita buat rilis lebih sulit untuk dipublikasikan”, dan hanya akan mengajari orang cara mengakalinya.
      Khususnya, tidak satu pun dari keduanya yang akan mencegah backdoor xz-utils masuk ke distribusi paket. xz-utils tetap menjadi patokan untuk kompromi hulu yang canggih.
      Bug di sini bukan bahwa kita perlu mengautentikasi hulu yang sudah kita percaya dengan lebih baik, melainkan bahwa kita tidak bisa mempercayai hulu sebagai satu-satunya sumber keamanan. Hulu adalah kumpulan peretas yang umumnya tidak terlalu peduli pada release engineering yang kokoh dan juga tidak terlalu mahir melakukannya.
      Tapi ada orang-orang yang memang mahir dalam hal itu. Solusi di dunia Linux, dan cara yang menyelamatkan kita dari xz-utils, adalah adanya lapisan manusia kedua yang meninjau, mengaudit, memaketkan, dan menyesuaikan hulu buatan para peretas itu untuk para pengguna.
      Orang-orang ini punya sudut pandang lain, kebutuhan konsumen yang lain, dan standar kualitas yang lain, sehingga mereka bisa menangkap bug dan niat jahat yang belum siap ditangkap oleh pihak hulu.
      NPM, cargo, PyPI, dan lain-lain terus berpikir bahwa kebutuhan akan tenaga manusia ini bisa dilewati, padahal tidak bisa. Ekosistem NPM khususnya punya banyak pengembang web yang terbiasa dengan rilis sangat cepat, tuntutan kompatibilitas yang longgar, dan penggunaan ulang yang ekstrem, sehingga hal seperti ini lebih sering terlihat pada paket node dibandingkan Python atau Rust.

  • Perusahaan kami memakai yarn 4, dan ada opsi untuk memblokir pemasangan paket npm selama beberapa hari pertama setelah dirilis. Sebagian besar serangan seperti ini tampaknya tertangkap dalam periode itu (1~3 hari)
    https://gist.github.com/mcollina/b294a6c39ee700d24073c0e5a4e...

  • Ada beberapa saran. Cooldown dependensi 1~2 hari tampaknya sangat efektif tanpa merusak kemampuan patch CVE
    Semua tempat yang menjalankan kode seperti npm install, npm test harus berjalan di lingkungan tanpa hak istimewa. Di GitHub Actions, ini relatif mudah dilakukan dengan memisahkan job yang membangun/menguji artefak dari job yang melakukan deployment/penandatanganan, dan sebagainya. Jika memakai AI, cukup tambahkan skill/panduan yang memaksa pola ini
    Jika Anda memakai GitHub Actions, memasang zizmor versi terbaru akan sangat meningkatkan postur keamanan
    Langkah kedua membuatnya tidak lagi bisa “menyebar seperti worm”, dan mengurangi porsi besar dari masalah saat ini. Langkah pertama memberi perusahaan waktu untuk merespons serangan. Beberapa vendor di bidang ini juga layak dievaluasi

    • Bagaimana kalau zizmor dikompromikan?
      Agak lucu sebagai lelucon, tepat setelah mengatakan bahwa paket baru harus ditunda
    • Daripada cooldown seperti ini, bukankah cukup menjalankan build dalam konteks terisolasi?
      Menjalankan proxy Maven secara lokal, dan semua build dilakukan di dalam kontainer. Python, npm, dan Go hanya memakai repositori publik, jadi build ini juga dijalankan dalam kontainer tetapi tidak memerlukan proxy repositori
    • Jika maksudnya semua tempat yang menjalankan kode, orkestrator berbasis agen seperti codex dan claude-code tampaknya sudah melakukan itu secara default

  • Ini terjadi pada hari yang sama ketika Red Hat dan IBM mengumumkan Project Lightwell, yang membantu mendeteksi dan memperbaiki kerentanan rantai pasok
    https://www.redhat.com/en/lightwell

  • Beberapa hari lalu melihat rant menarik ini: https://github.com/uNetworking/uWebSockets.js/blob/master/mi...
    Ada benarnya juga bahwa cara yang tepat adalah mem-fork semua dependensi yang dipakai, lalu meninjau dan menggabungkan perubahan upstream saat diperlukan sambil menginstalnya dari repositori sendiri. Hanya saja, itu terdengar sangat merepotkan

    • Ini bukan hal yang tidak bisa diotomatisasi. Di dunia Go, ini bisa disebut vendoring: https://go.dev/ref/mod#vendoring
      Ini bagus untuk mengurangi atau menghilangkan ketergantungan pada penyedia hosting dependensi pihak ketiga, membawa dependensi ke dalam alat code review sendiri, dan dalam jangka panjang menjamin build yang dapat direproduksi
    • Masalahnya adalah dependensi dari dependensi, dan itu terus berlanjut sampai beberapa tingkat di bawahnya
    • Saya membuat Packj agar dependensi bisa diaudit dengan mudah dari CLI
      Packj(https://github.com/ossillate-inc/packj) mendeteksi dependensi berbahaya di PyPI/NPM/Ruby/PHP dan lainnya melalui analisis perilaku. Dengan analisis kode statis + dinamis, ia memindai indikator kompromi seperti eksekusi shell, penggunaan kunci SSH, komunikasi jaringan, serta penggunaan decode+eval. Ia juga memeriksa berbagai properti metadata untuk menemukan pelaku berbahaya seperti typosquatting
    • Peluangnya mungkin bisa diubah, tetapi jika tidak rajin mem-fork dan melakukan monkeypatch untuk semua kerentanan ke depannya, Anda bisa saja mendistribusikan fork yang sudah dikompromikan selamanya
    • Bukankah paket seharusnya tidak hanya dijaga tetap terbaru, tetapi juga nomor versinya dibatasi?

  • Sekitar seminggu lalu saya menghapus Node dari laptop, dan rasanya menyenangkan
    Untuk mengurangi radius dampak kalau sialnya terkena eksploit, saya sedang mencoba melakukan semua pekerjaan di dalam development container atau sandbox lain. Penyerang mungkin bisa mengambil token Claude, tetapi tidak akan bisa dengan mudah keluar dari container lalu mengobrak-abrik home directory saya
    Cooldown dan allowlist skrip instalasi adalah lapisan tambahan yang bagus untuk keamanan berlapis, terutama di CI. Namun pada dasarnya, menurut saya yang harus berubah adalah model perizinan sistem operasi. Default yang mempercayai perangkat lunak pihak ketiga dengan seluruh hak pengguna sudah tidak lagi berfungsi

    • Penasaran apakah Anda memakai hal seperti Bubblewrap/Firejail/Flatpak, atau seperti apa konfigurasi semacam itu. Sudah lama memikirkan ide serupa tapi belum sempat menjalankannya

  • Sepertinya perlu menautkan pengumuman aslinya
    https://www.stepsecurity.io/blog/multiple-redhat-cloud-servi...

    • Benar. Dan ejaan Red Hat di judulnya juga salah

  • Saat memasang paket, saya sekarang jadi terbiasa memakai flag --before=2026-05-30. Itu memaksa memilih versi yang dirilis sebelum tanggal yang ditentukan, dan biasanya saya memilih sekitar 5 hari sebelumnya

  • NPM sudah rusak sejak desainnya, dan sindrom NIH yang merajalela di komunitas membuat bahkan langkah sederhana pun tidak bisa dilakukan

    • Saya kurang paham kalimat kedua. Bukankah npm justru punya masalah yang berkebalikan dari ‘not invented here’?
      Karena terlalu banyak menerima paket eksternal alih-alih mengembangkan sendiri, proyek npm cenderung memiliki pohon dependensi yang besar dan rumit. Keluhan tentang paket seperti https://www.npmjs.com/package/is-windows sudah lama ada, karena kode seperti itu terlalu mudah ditulis sendiri tetapi tetap menciptakan potensi kerentanan dan masalah pemeliharaan
    • Kekeliruan yang umum di kubu NIH adalah anggapan bahwa membuat ulang paket X akan memakan banyak waktu
      Padahal tentu tidak perlu membuat ulang semua fiturnya, cukup buat fungsi yang dibutuhkan saja
      Selain itu, saat hanya menulis satu fungsi, tidak perlu membuat abstraksi atau antarmuka fungsi tambahan. Jadi lebih murah, dan kemungkinan terintegrasi lebih baik
      Kekeliruan lain adalah anggapan bahwa itu akan menciptakan bug dan kerentanan. Jika programernya buruk, mungkin iya, tetapi setidaknya Anda bisa menghindari kategori kerentanan yang muncul di batas integrasi antara dua pustaka yang tidak dirancang agar saling cocok secara tepat. Kasus seperti itu cukup sering terjadi