Untuk sementara, mungkin lebih baik tidak memasang perangkat lunak baru

• Setelah copy.fail, kerentanan kernel Linux tambahan telah diumumkan
• Saat ini dinilai sebagai momen ketika serangan rantai pasok NPM dapat menimbulkan dampak besar
• Ada anjuran untuk mengecualikan patch kernel Linux yang disediakan oleh distribusi
• Selain itu, sebaiknya hentikan pemasangan perangkat lunak baru selama sekitar satu minggu
• Ada catatan bahwa setelah posting ini diterbitkan, fakta atau situasi mungkin telah berubah, sehingga jika ada bagian yang tampak salah atau tidak jelas, diminta untuk menghubungi sebelum menarik kesimpulan

[GN⁺]

Komentar Hacker News

• Ini memang mimpi buruk yang sejak lama rasanya pasti akan meledak. Jumlah paket terlalu banyak, dan akibatnya permukaan serangan rantai pasok jadi sangat besar; cepat atau lambat ini memang akan menimpa semua orang
  Tapi semuanya terlalu nyaman. Orang-orang yang mencoba memperingatkan atau mengurangi risikonya diabaikan oleh mereka yang belum pernah mencoba cara lain, dan "import antigravity" terlalu mudah untuk ditinggalkan
  Sepertinya sekarang kita sudah masuk ke fase “membayar harganya”

  • Di satu perusahaan, operasinya benar-benar sangat konservatif. Semua komponen eksternal dipatok versinya, tidak diperbarui tanpa peninjauan, dan biasanya melewati masa stabilisasi yang cukup lama
    Hampir semuanya, termasuk compiler dan kernel, dibangun dari source, server/infrastruktur build sama sekali tidak punya akses internet, dan ada prosedur khusus untuk membawa masuk perubahan. CVE yang relevan juga ditinjau setiap kali dipublikasikan untuk menilai apakah berdampak pada kami dan bagaimana mitigasi atau penanganannya
    Setelah pindah ke perusahaan lain, build bisa mengakses internet, dan upgrade dilakukan begitu versi baru keluar. Orang menganggap ini praktik yang baik karena mendapatkan perbaikan bug terbaru, dan peninjauan CVE ditangani tim keamanan
    Startup berikutnya punya campuran berbagai praktik. Ada beberapa hal yang sangat bagus, tetapi juga punya utang CVE yang besar. Misalnya, mereka menerapkan secure boot dan disk terenkripsi di server, dan pemahaman tentang keamanan komunikasi antarkomponen juga cukup baik
    Semua orang merasa cara merekalah yang benar. Hampir mustahil meyakinkan orang yang “sering upgrade” bahwa ada risiko memperkenalkan masalah baru. Industri ini butuh paket praktik yang lebih baik, dan secara pribadi saya menilai cara perusahaan pertama mengelola dependensi itu lebih baik. Secara keseluruhan praktik keamanannya matang dan produknya juga benar-benar aman
  • Kalau sekalian membuka kotak Pandora, bagaimana kalau efek bersih dari membongkar semua vektor serangan yang belum diketahui ini adalah menghabiskan stok kerentanan simpanan badan intelijen di seluruh dunia
    Semua perangkat lunak yang berguna jadi telah melalui fuzz testing, property testing, dan verifikasi formal, sehingga semua pihak yang mencari kerentanan harus mulai lagi dari nol
    Tentu saja, itu dengan asumsi kita bisa bertahan melewati masa jeda ketika negara-negara melempar semua sisa amunisi mereka ke musuh terburuknya. Atau ya, pada akhirnya mungkin kita tinggal saling pukul pakai tulang binatang
  • Saya sudah bertahun-tahun menginginkan model keamanan berbasis capability, dan pernah berdebat soal ini juga di sini. Capability itu seperti pointer objek yang membawa hak terkait, mirip file descriptor Unix
    Di level OS, program yang dijalankan menerima token capability dari shell atau dari tempat yang meluncurkannya, dan setiap system call harus menerima capability sebagai argumen pertama. Jadi "open path /foo" menjadi open(cap, "/foo"). Capability ini bisa merujuk ke filesystem palsu, satu cabang dari filesystem nyata, filesystem jaringan, atau apa pun, dan program tidak perlu tahu sandbox seperti apa yang ditempatinya
    Di level library/bahasa juga, saat mengimpor library pihak ketiga seperti modul npm, capability harus diberikan pada saat import atau di setiap lokasi pemanggilan. Library itu tidak seharusnya mendapat akses baca/tulis ke setiap byte di ruang alamat program saya, dan juga tidak boleh bisa melakukan apa saja di komputer saya seolah-olah ia adalah saya. Pertanyaan intinya adalah: seberapa jauh blast radius kode ini? Jika library yang saya pakai ternyata berbahaya atau rentan, kita butuh default yang masuk akal untuk membatasi skala kerusakan. Pemanggilan lib::add(1, 2) tidak boleh berujung pada kompromi persisten atas seluruh komputer saya
    SeL4 sudah lama menyediakan capability di level OS yang cepat dan efisien, dan itu bekerja dengan baik. Dalam banyak kasus lebih cepat dari Linux, dan sangat berguna untuk sandboxing transparan, driver user-space, komunikasi antarproses, dan peningkatan keamanan. Linux bahkan bisa dijalankan sebagai proses di atas SeL4. Saya ingin OS yang punya semua fungsi desktop Linux tetapi berperilaku seperti SeL4
    Sayangnya, tampaknya belum ada bahasa pemrograman yang punya capability di level bahasa dalam bentuk yang saya inginkan. Rust cukup dekat, tetapi perlu ada cara membatasi agar crate pihak ketiga tidak bisa memanggil unsafe code apa pun, termasuk unsafe yang dipanggil oleh dependensi yang tidak dipercaya. Bug soundness Rust yang sudah lama juga perlu diperbaiki, dan kita juga butuh standard library berbasis capability. Hal seperti open() / listen() global harus hilang, dan yang boleh ada hanya bentuk setara openat() serta padanannya untuk bagian OS lain
    Jika LLM terus membaik, dalam beberapa tahun lagi, kalau belum ada yang membuatnya lebih dulu, saya akan menyuruh LLM membangun semua ini. Keamanan OS desktop modern itu sudah seperti lelucon
  • Kebanyakan orang pada dasarnya tidak memasukkan sembarang hal ke mulut mereka. Mereka tidak menunggu hasil kultur mikroba dinyatakan positif dulu baru menolaknya
    Kode juga butuh budaya higienitas, dan itu tidak jauh berbeda dari norma yang dikembangkan kebanyakan budaya terhadap makanan. Ini memang gabungan heuristik kasar, tetapi rasa “ih” itu sudah menyelamatkan miliaran orang
  • Setahun lalu saya sempat mengemukakan bahwa sebisa mungkin lebih baik menulis kodenya sendiri daripada menarik pihak ketiga. Waktu itu, bahkan mempertimbangkan LLM untuk menutup celah dianggap seperti bidah
    Sekarang saya mengurangi paparan dependensi lebih keras daripada sebelumnya, terutama untuk hal-hal yang bisa diimplementasikan hanya dengan beberapa ratus baris. Ini benar-benar pergeseran paradigma

• Pendekatan “tunggu seminggu sebelum memasang software” tidak akan berhasil. Baru beberapa bulan lalu ada kerentanan besar yang menghantam web, dan itu merupakan serangan tertunda waktu yang aktif setelah bersembunyi lebih dari sebulan
  Kalau semua orang mulai menunggu seminggu, penyerang akan menunggu dua minggu. Penjahat siber tidak perlu mengeksploitasinya segera; yang penting pada akhirnya tetap berhasil mengeksploitasi. Banyak jenis kerentanan seperti typosquatting juga tidak berubah dengan pendekatan ini

  • Sepertinya maksud penulis bukan menunda semua pembaruan terus-menerus, melainkan sekali saja menunggu seminggu sampai perbaikan dan distribusi patch untuk kerentanan spesifik yang kali ini dipublikasikan terlalu dini bisa dilakukan. Untuk selain itu saya setuju
  • Sepertinya Anda salah memahami tulisannya. Sarannya bukan menunggu seminggu setelah software dirilis baru dipasang. Maksudnya adalah: mulai sekarang, selama 7 hari ke depan, jangan pasang apa pun dulu
    Karena besar kemungkinan patch untuk kerentanan ini belum ada, dan kalaupun ada, sangat mungkin akan segera ditemukan kerentanan lain yang lebih menakutkan
  • Kalau begitu, ya tinggal tunggu sebulan atau dua bulan. Inti masa tunggu ini bukan mencegah eksekusi exploit yang sudah terpasang, melainkan menghindari pemasangan exploit baru
  • Paket populer punya paparan lebih besar. Saat artefak dipublikasikan, seluruh dunia bisa melihatnya, dan Anda bisa mengharapkan seseorang memeriksa perbedaan antarversi
    Tetapi jika tidak ada jeda sama sekali, Anda bisa terkena exploit yang belum sempat dilihat siapa pun
  • Semua kompromi dependensi yang saya ingat selama “beberapa bulan terakhir” terdeteksi dalam hitungan menit, bukan jam. litellm, axios, bitwarden CLI, image Docker Checkmarx, Pytorch lightning, intercom/intercom-php termasuk di antaranya
    Lagi pula, penemuan kompromi seperti ini sama sekali tidak bergantung pada apakah sudah benar-benar dieksploitasi atau belum. Jadi saya tidak paham dengan pernyataan “kalau semua orang menunggu seminggu, penyerang akan menunggu dua minggu”

• Alternatif lain, Anda bisa pindah ke OS seperti FreeBSD yang tidak menerapkan pendekatan keamanan gaya YOLO
  Perbaikan keamanan tidak begitu saja dilempar ke kernel FreeBSD tanpa koordinasi. Semuanya melalui tim keamanan FreeBSD, dan dalam beberapa menit setelah patch masuk ke src tree, pembaruan biner didistribusikan lewat FreeBSD Update dan pkgbase untuk 15.0-RELEASE
  Kira-kira cuma butuh beberapa detik sampai ada pesan di Slack bahwa “patch sudah di-push”, 10–30 detik untuk mengunggah patch, dan paling lama sekitar 1 menit untuk sinkronisasi mirror

  • Soal ini saya agak skeptis. Beberapa tahun lalu saya melaporkan kerentanan ke tim keamanan FreeBSD, lalu mengirim email tindak lanjut beberapa minggu kemudian, tetapi tidak pernah mendapat balasan
    Demi adil, laporan saya bukan tentang komponen inti dan juga tidak mudah dieksploitasi, tetapi Debian, OpenBSD, SUSE, dan Gentoo semuanya menambal dalam waktu seminggu https://www.maxchernoff.ca/p/luatex-vulnerabilities#timeline
    Ini bukan berarti seluruh OS harus dinilai hanya dari penanganan satu laporan kecil. Justru dari semua hal lain yang saya lihat, FreeBSD cenderung menangani laporan keamanan dengan cukup serius. Hanya saja, logika yang sama juga bisa diterapkan ke bug kernel Linux. Kasus patch yang dikelola seburuk itu juga cukup jarang di Linux
  • Kalau pindah ke BSD demi keamanan, kenapa FreeBSD? Bukankah OpenBSD yang sangat kuat di sisi keamanan? Saya bertanya karena sudah lama tidak mengikuti proyek-proyek itu
  • FreeBSD cukup longgar soal keamanan, terutama dalam hal default dan konfigurasi
    Cenderung mengutamakan kegunaan dibanding keamanan. Contoh terkenalnya ada di sini: https://vez.mrsk.me/freebsd-defaults
    Saya menghargai kontribusi terhadap proyek ini, tetapi selama default buruk seperti itu masih ada, saya tidak bisa dengan hati nurani menyarankan orang untuk pindah
  • FreeBSD bahkan tidak punya ASLR user-space sampai 2019, dan kASLR, salah satu mitigasi lainnya, juga masih belum ada. Bagi orang yang peduli keamanan, itu bukan OS yang serius
    Kalau mau FreeBSD dan keamanan, lebih masuk akal memakai HardenedBSD buatan Shawn Webb
  • Dalam diskusi seperti ini memang selalu ada saja yang muncul. Syukurlah distro favorit Anda pasti lebih aman. Walaupun exploit berkurang dari ribuan menjadi sekadar kelipatan satu digit, tetap saja akan tersisa ribuan juga. Ozymandias pasti pakai Gentoo

• Bahkan para ahli keamanan sekarang juga harus menerima bahwa dunia kita berdiri di atas keseimbangan yang sangat rapuh. Menurut saya orang benar-benar meremehkan hal ini
  Bukan cuma dunia IT; seluruh dunia dibangun di atas banyak sekali keseimbangan yang sangat rapuh. Exploit keamanan akan selalu ada. Bukan cuma di software, di dunia nyata juga sama. Ada orang yang menyusup ke konferensi keamanan, dan itu bahkan cuma seorang YouTuber. Memang bukan acara dengan keamanan superketat, tapi itu contoh yang terlintas di kepala. Pada dasarnya, di kebanyakan kasus, menembus keamanan itu sangat mudah
  Maksud saya, pada level fundamental dunia kita berfungsi setidaknya karena sebagian besar orang memilih untuk tidak menyalahgunakannya. Masyarakat manusia memang selalu bekerja seperti itu, dan kemungkinan besar akan terus begitu

  • Saya ingat sempat ada tren di kalangan influencer Inggris untuk masuk ke suatu tempat dengan trik “tangga dan rompi reflektif” demi menunjukkan betapa rapuhnya keamanan fisik https://www.youtube.com/watch?v=LTI0SeyhAPA
    Setahu saya YouTuber bernama Max Fosh sempat berhasil masuk ke International Security Expo beberapa kali berturut-turut. Di Inggris dia memakai nama samaran “Rob Banks” di https://www.youtube.com/watch?v=qM3imMiERdU, dan di AS “Nick Everything” di https://www.youtube.com/watch?v=NmgLwxK8TvA
    Saya pernah mempelajari budaya keamanan, dan pada akhirnya kebanyakan hal jatuh pada skala geser antara keamanan di satu sisi dan kenyamanan/aksesibilitas di sisi lain. Semakin aman, semakin kurang mudah diakses, dan sebaliknya

• Untuk serangan rantai pasok pada manajer dependensi seperti npm, PyPI, dan Cargo, sebenarnya sudah ada solusi yang lumayan baik. Atur agar hanya versi paket yang sudah berumur beberapa hari yang boleh dipasang
  Semua serangan besar belakangan ini ditemukan dan dibatalkan dalam waktu kurang dari sehari, jadi pendekatan ini akan menghindarinya dengan aman. Perilaku ini seharusnya menjadi default. Biarkan beta tester yang memang memilihnya sendiri dan perusahaan pemindai keamanan memakai versi paket terbaru sehari lebih dulu. Caranya ada di sini: https://cooldowns.dev/

  • Alat seperti ini yang muncul di Show HN 3 bulan lalu tampaknya lebih tepat: https://github.com/artifact-keeper
    Ini adalah manajer artefak. Ia memungkinkan Anda hanya menarik hal yang sudah disetujui. Anda bisa memperbaruinya cepat saat perlu, dan tetap memakai versi stabil yang tervalidasi secara konsisten saat itu yang dibutuhkan. Memang perlu sedikit override konfigurasi, tetapi itu pekerjaan yang mudah
    Saya pernah membuat dan memakai alat seadanya dengan tujuan serupa, dan ini proyek yang bagus
  • Cara yang lebih baik adalah memakai hanya repositori yang sudah diverifikasi perusahaan, dan jangan biarkan siapa pun memasang langsung dari repositori internet
    Tentu saja, di luar lingkungan perusahaan ini secara alami tidak terlalu berjalan
  • Tapi bukankah itu juga berarti pembaruan keamanan diterima lebih lambat? Banyak kerentanan sudah ada di lingkungan nyata selama bertahun-tahun sebelum ditemukan dan ditambal
    Begitu ditemukan, ledakan exploit langsung terjadi, dan menunda pembaruan memberi lebih banyak waktu kepada penyerang yang sedang bersemangat
  • Secara pribadi saya rasa pendekatan yang paling berkelanjutan adalah model Linux distribution/BSD ports/Homebrew. Bukan langsung mendorong library baru ke registry publik, melainkan menulis skrip pemaketan yang ditinjau setiap kali ada perubahan baru
    Model lain adalah CPAN milik Perl, yang hanya mendistribusikan source file

• Bagi yang relatif baru mengadopsi continuous integration dan build terkontainerisasi, ada baiknya memeriksa apakah sistem Anda tidak menarik latest dari banyak paket di setiap build
  Kami membuat container dasar yang sudah memuat semua dependensi eksternal, lalu hanya memperbaruinya secara eksplisit ketika kami menilai waktunya memang tepat
  Jadi memang bisa sedikit tertinggal dari yang paling mutakhir, tetapi risikonya jauh lebih kecil dibanding langsung menyebarkan kerentanan rantai pasok acak ke seluruh dunia

  • Anda juga akan mendapati bahwa ini sangat mengurangi waktu build CI dan kegagalan acak yang tidak stabil
  • Selain itu, sebaiknya pakai repositori internal saja

• Ini tulisan opini yang secara aktif merugikan. Sulit memahami logikanya
  Hanya butuh 45 detik untuk mengecek sudah berapa lama kerentanan copyfail dan dirtyfrag sebenarnya ada. Memang lebih lama daripada membaca artikelnya. Dirtyfrag bisa relevan untuk sistem yang jejaknya mundur sampai 2017
  Yang terdampak bukan software yang “baru”. Dan software lama justru keadaannya lebih buruk karena punya jauh lebih banyak waktu untuk dicari masalahnya

  • Tulisan aslinya menyarankan bahwa jika sekarang terjadi serangan rantai pasok, dampaknya bisa buruk, jadi sebaiknya jangan memasang/memperbarui paket NPM untuk mengurangi risiko itu

• Suatu hari nanti seseorang akan membangun ulang seluruh stack dari OS sampai aplikasi dengan upgrade proof-carrying code
  Satu-satunya cara menjalankan kode yang benar-benar tepercaya adalah desain bersama dan pembangunan bersama antara proof dan code

• Ini bukan cuma berlaku untuk software, tapi sebenarnya untuk hampir semua hal
  Saya tidak ingat membaca ini di mana, tetapi pada akhirnya ini bermuara pada perbedaan antara kebutuhan dan keinginan
  Saya sudah memakai aturan ini saat memutuskan apakah akan membeli mobil baru atau mobil bekas, membeli vacuum cleaner kelas atas atau yang standar. Hal yang sama berlaku untuk perangkat baru yang mengilap, memasukkan sesuatu yang baru ke tech stack, atau memilih tech stack baru

• Saya ingin dibantu memahami apa itu copyfail dan bagaimana hubungannya dengan paket NPM
  Setelah saya rangkum, sepertinya copyfail adalah bug kernel yang bisa memungkinkan paket npm berbahaya mendapatkan hak root di server Linux
  Jadi ini berarti sekarang adalah saat yang tepat bagi penyerang untuk membidik paket NPM, karena masih ada server yang belum ditambal
  Apakah alasan sarannya bukan sekadar “perbarui kernel” adalah karena masalah baru terkait masih terus ditemukan dan belum semuanya tertambal?

  • Patch untuk kerentanan-kerentanan terbaru bahkan belum dirilis. Jadi kalau sekarang terjadi serangan rantai pasok baru, itu akan jadi waktu yang sangat buruk karena hampir semua sistem bisa memperoleh root
  • Serangan rantai pasok NPM menyebar sangat cepat
    Jika paket NPM populer dikompromikan dan menyertakan exploit copy.fail, banyak sistem akan rentan terhadap eskalasi hak root
  • Alasan sarannya bukan “perbarui kernel” adalah karena memang belum ada pembaruannya. Kerentanan terbaru yang ditemukan setelah copy.fail masih belum diperbaiki