Meretas ekosistem Nix

• Peneliti membagikan pengalamannya menemukan kerentanan di Nixpkgs yang memungkinkan penyuntikan kode berbahaya ke seluruh ekosistem Nix
• Menjelaskan risiko struktural pada GitHub Actions melalui trigger pull_request_target, yang dapat mengekspos hak akses sensitif dan secret bahkan pada PR dari kontributor eksternal
• Membuktikan bahwa pemeriksaan editorconfig dan tugas verifikasi code owners benar-benar dapat dieksploitasi untuk eskalasi hak akses melalui penyisipan perintah dan pemanfaatan symbolic link
• Segera setelah temuan, tim pengelola Nixpkgs dengan cepat memperbaiki kerentanan, menonaktifkan workflow yang rentan, dan meninjau ulang pengelolaan izin
• Menekankan pentingnya memisahkan data tak tepercaya dari operasi sensitif dalam infrastruktur CI/CD, menerapkan hak akses minimum, dan memperkuat kebijakan

---

Meretas seluruh ekosistem Nix

Pengantar dan latar belakang

• Pada NixCon tahun lalu, peneliti dan rekannya Lexi mempresentasikan kerentanan di Nixpkgs
• Kerentanan yang ditemukan ini membuka kemungkinan penyisipan kode berbahaya ke seluruh ekosistem Nix melalui serangan rantai pasok
• Ini adalah pengalaman respons cepat, dari deteksi kerentanan hingga pelaporan dan penanganan, yang selesai hanya dalam satu hari
• Karena peneliti tidak bisa menghadiri NixCon tahun ini, proses tersebut dirangkum secara rinci melalui tulisan ini

GitHub Actions: target yang rentan

• GitHub Actions adalah sistem yang mendukung berbagai tugas otomatisasi (CI/CD) di repositori kode
• Jika memiliki akses untuk mengubah file workflow, penyisipan kode menjadi mudah, sehingga ia menjadi target utama serangan rantai pasok
• File workflow ditulis dalam YAML, dan karena format ini tidak dirancang khusus untuk eksekusi, ada kerentanan keamanan tak terduga yang bisa muncul
• Sebagai contoh sederhana, ada workflow yang menjalankan perintah saat kode di-push

Trigger pull_request_target yang berbahaya

• GitHub Actions memiliki beberapa trigger, dan pull_request_target sangat berbeda dari pull_request biasa
• pull_request_target secara bawaan memiliki hak akses read/write dan akses ke secret bahkan dari fork (PR)
• Jika trigger ini digunakan secara keliru, data eksternal yang tidak tepercaya akan digabungkan dengan izin sensitif
• Dokumentasi resmi GitHub juga memperingatkan risiko ini secara jelas
• Peneliti memeriksa 14 workflow di repositori Nixpkgs yang menggunakan pull_request_target

Kerentanan editorconfig-checker

• Workflow rentan pertama yang ditemukan bertujuan untuk memeriksa aturan editorconfig
• Setelah menghitung daftar file yang berubah, workflow meneruskannya ke editorconfig-checker menggunakan xargs
• Jika peringatan keamanan pada perintah xargs diabaikan, muncul kerentanan yang memungkinkan penyisipan nama file yang dirancang secara jahat (misalnya --help)
• Dengan cara ini, editorconfig-checker dapat dimanipulasi secara sewenang-wenang atau membuka kemungkinan eksekusi perintah tambahan (analisis rinci masih memerlukan peninjauan lebih lanjut)

Kerentanan codeowners-validator: menyertakan file lokal

• Kerentanan kedua yang lebih serius ditemukan pada workflow validasi file CODEOWNERS
• Proses ini melakukan checkout pada kode PR lalu memeriksa file dengan codeowners-validator
• Pengirim PR dapat mengganti file OWNERS dengan symbolic link, sehingga bisa merujuk ke file arbitrer di dalam runner (misalnya kredensial action)
• Akibatnya, isi file tersebut tercetak ke log saat validasi sehingga token GitHub dengan hak read/write terekspos
• Jika token ini diperoleh, penyerang dapat langsung melakukan push ke repositori Nixpkgs

Tindakan dan pelajaran

• Setelah laporan kerentanan disampaikan, maintainer Nixpkgs infinisil segera merespons
  • Menonaktifkan sementara workflow yang rentan
  • Memperbaiki dan memisahkan bagian yang menghubungkan data tak tepercaya dengan izin
  • Setelah perbaikan keamanan, mengganti nama workflow untuk mengurangi masalah branch targeting
• Pelajaran utama
  • Data yang tidak tepercaya tidak boleh digabungkan dengan secret dan operasi sensitif, atau setidaknya harus ditangani dengan sangat hati-hati
  • Mematuhi prinsip hak akses minimum
  • Wajib memahami panduan resmi terkait izin GitHub Actions
• Jika kerentanan serupa muncul, admin organisasi dapat menonaktifkan Actions secara massal lewat kebijakan (tersedia petunjuk pengaturannya)

Kesimpulan

• Dalam satu hari, peneliti menemukan kerentanan yang bisa membahayakan seluruh ekosistem Nix, melaporkannya, dan ikut membantu perbaikannya
• Hal ini menunjukkan perlunya kehati-hatian ekstra saat menggunakan GitHub Actions, khususnya pull_request_target
• Peneliti menyampaikan terima kasih kepada Intrigus dari KITCTF yang membantu riset serta infinisil yang merespons dengan cepat
• Pembaca yang tertarik disarankan melihat video presentasi dan materi tambahan
• Secara keseluruhan, tulisan ini menekankan pentingnya pengelolaan keamanan GitHub Actions dan pelajaran praktis di lapangan

[GN⁺]

Opini Hacker News

• Saya rasa pull_request_target pada dasarnya rentan secara keamanan, dan GitHub seharusnya menghapus fitur ini sama sekali. Biasanya orang bilang pull_request_target bisa dipakai dengan aman selama Anda tidak menjalankan kode yang dikendalikan dari branch saat proses berjalan, tetapi dalam praktiknya permukaan serangannya jauh lebih luas karena injeksi argumen, local file inclusion, dan sebagainya. Saat ini use case yang benar-benar sah paling hanya pelabelan otomatis atau menambahkan komentar otomatis pada PR pihak ketiga. Saya rasa tugas seperti ini tidak perlu diberi izin tulis ke repositori secara default. GitHub seharusnya bisa menerbitkan token yang dibatasi hanya untuk tugas tersebut. Karena itu, di zizmor saya menandai semua penggunaan trigger berbahaya seperti pull_request_target; lihat zizmor dangerous triggers

  • Saya juga setuju, tapi ada use case ketika organisasi tidak mengizinkan fork. Beberapa tool memproses merge di luar github, dan dalam kasus seperti itu bisa muncul PR dengan merge yang tidak bersih sehingga workflow pull_request tidak terpicu. Dalam situasi ini pull_request_target praktis menjadi satu-satunya opsi. Akan lebih baik kalau github menyediakan pengaturan untuk menjalankan workflow pada PR dengan merge yang tidak bersih, dinonaktifkan secara default, dan dipakai hanya untuk hal seperti linter. Sebelum itu ada, sangat disayangkan bahwa karena keterbatasan ini kita terpaksa hanya bisa memakai pull_request_target. Sebagai catatan, kalau memakai tool eksternal seperti ini lalu melakukan merge manual di github, seluruh alurnya akan rusak, jadi merge manual benar-benar tidak boleh dilakukan
  • Di repo privat saya memakai pull_request_target karena dua alasan. Pertama, workflow selalu dijalankan berdasarkan main sehingga kode test yang belum diverifikasi bisa diblokir. Kedua, dalam sub-claim JWT di workflow, job_workflow_ref disediakan secara krusial sehingga sistem berbasis OIDC bisa melakukan kontrol akses yang rinci
  • Menurut penjelasan GitHub, pull_request_target berjalan dalam konteks base PR sehingga kode berbahaya tidak bisa mencuri repo atau secret. Tapi sebenarnya kalau tahu betapa mudahnya membocorkan secret dalam praktik, situasinya agak menggelikan
  • Permukaan serangan seperti ini sudah hampir setahun tidak terselesaikan. Perlu diingat kasus ketika paket python terkena branch name berbahaya yang berisi kode mirip shellshock. Ada juga blog yang merangkum variabel rentan dan metode serangannya dari sudut pandang penetration tester

• Jika tim Nix telah mengadopsi signed commit/review dan reproducible build yang ditandatangani secara independen seperti RFC yang saya usulkan, serangan supply chain last-mile seperti ini tidak akan mungkin terjadi. Pada akhirnya NixPkgs ingin siapa pun bisa mengedit dengan mudah dan takut bahwa upaya yang terlalu peduli keamanan akan mengusir para relawan; fokusnya adalah distro untuk hobi. Itu tidak masalah, tetapi jika ingin menjelaskan karakteristik ini dengan jelas kepada orang-orang dan melindungi hal yang benar-benar berharga, kita harus berhenti menggunakan atau merekomendasikan Nix untuk lingkungan yang kritis terhadap keamanan. OS yang bertujuan melindungi sesuatu harus mewajibkan tanda tangan hardware dua pihak yang ketat untuk semua perubahan, dan tidak boleh mempercayakan kepercayaan pada satu komputer atau satu orang. Itulah sebabnya saya membuat Stagex tautan Stagex tautan Codeberg

  • Pertama, ini bukan posisi resmi, tetapi saya ingin berkomentar sebagai kontributor yang berusaha meningkatkan keamanan di nixpkgs. Mungkin RFC yang Anda maksud adalah RFC 0100 "Sign Commits" (tautan). Seperti dibahas dalam RFC itu, hambatan terbesarnya adalah tidak adanya dukungan penandatanganan commit di perangkat mobile. nixpkgs tidak punya kapasitas untuk sampai mengurus pengembangan tooling mobile. Saya sendiri menandatangani commit dan berupaya meningkatkan provenance, tetapi pada dasarnya push tetap bisa dilakukan dengan commit unsigned atau key yang tidak tepercaya. Untuk proyek yang mengutamakan keamanan seperti Stagex, lapisan keamanan seperti ini tentu diperlukan. Namun nixpkgs punya filosofi keandalan yang berbeda. Saya tidak setuju dengan kebijakan keamanan yang bisa membuat relawan kabur, jadi saya penasaran statistik seberapa besar fitur seperti ini benar-benar akan dipakai di nixpkgs. nixpkgs bukan sekadar distro hobi; perusahaan besar juga banyak memakainya dalam praktik (cukup lihat daftar sponsor NixCon 2025). Mengaktifkan lebih banyak fitur keamanan adalah hal positif, dan saya rasa situasinya bisa berubah di masa depan. Tetapi saat ini mewajibkan commit signing di nixpkgs menurut saya punya terlalu banyak dampak negatif. Selain itu, saya rasa saya belum melihat "independent signed reproducible builds" di PR tersebut, dan bagi skala seperti nixpkgs, membangun infrastruktur seperti itu oleh pihak ketiga sangatlah besar. Meski begitu, NixOS memang sedang mengarah ke build yang hampir sepenuhnya reproducible tautan status, dan sudah sangat dekat walau belum 100%. Kesimpulannya, signed commit memang akan berkontribusi pada keamanan yang lebih baik, tetapi efek negatifnya untuk nixpkgs juga besar sehingga saat ini sulit diterapkan. Saya penasaran dengan pendekatan two-party hardware signing milik Stagex; akan bagus kalau bisa dijelaskan. Terakhir, saya mengakui pekerjaan Stagex produktif dan menarik, saya hanya ingin meluruskan beberapa kesalahpahaman
  • Stagex benar-benar mengesankan, terima kasih sudah membagikan tautannya
  • Saya cuma ingin menyampaikan dukungan, ini proyek yang sangat menarik
  • Hari ini saya baru tahu tentang Stagex, dan ini penemuan paling menarik di thread ini
  • Wow... aneh rasanya mengetahui bahwa sesuatu yang sudah lama ingin saya lakukan ternyata sudah dilakukan orang lain

• Saya telah lama merancang sistem komputer, jadi saya sangat heran bahwa workflow modern masih menerbitkan bearer token—bahkan token berumur pendek—kepada program yang dipercayainya. Jika framework GitHub Actions hanya memberi akses ke unix socket istimewa atau ssh-agent, kerentanan seperti ini akan jauh lebih sulit dieksploitasi

  • Sangat setuju. Kita harus beralih dari bearer token ke skema berbasis tanda tangan, dan jika private key diekspos secara langsung, pada dasarnya itu tidak berbeda dari bearer token. Signing agent menjalankan peran ini. Walaupun github api berbasis HTTP, mutual TLS dan signing agent saja seharusnya sudah cukup
  • Standar SPIFFE melakukan hal yang mirip. Tapi tidak ada yang memakainya; saya rasa seluruh industri pada dasarnya tidak benar-benar serius soal keamanan

• Aksi CI/CD untuk pull/merge request benar-benar mimpi buruk. Saat developer menulis langkah test atau validasi, mereka biasanya berpikir dalam konteks "kode saya berjalan dalam konteks akun github/gitlab saya". Itu benar untuk commit mereka sendiri atau commit rekan satu tim, tetapi pada PR, pipeline CI/CD menjalankan kode yang tidak tepercaya. Sulit untuk selalu menyadari perbedaan ini dengan tepat, dan meski aman untuk sekadar menjalankan test atau linter, begitu tugas mulai perlu integrasi infrastruktur dan izin lebih besar, situasinya cepat menjadi berbahaya

  • Masalahnya bukan CI/CD dipicu oleh PR itu sendiri, melainkan GitHub punya dua trigger yang hampir sama (pull_request dan pull_request_target). Salah satunya (misalnya pull_request) hampir selalu aman kecuali sengaja disalahgunakan, sedangkan yang lain (misalnya pull_request_target) nyaris tidak bisa dipakai dengan aman. Masalah yang lebih besar adalah GitHub membuat tugas biasa seperti memberi label pada PR atau meninggalkan komentar otomatis hanya bisa dilakukan lewat trigger berbahaya (pull_request_target), sehingga semua orang terpaksa mengambil pilihan yang rapuh. Fitur yang disediakan GitHub Actions mendorong struktur yang mudah menimbulkan kesalahan

• Seiring waktu saya semakin khawatir soal serangan supply chain. Ini bukan cuma kekhawatiran seperti "apakah saya akan kehilangan pekerjaan karenanya" atau "muncul vektor serangan baru di NixOS, CI/CD, Node, dll.", melainkan kekhawatiran yang lebih filosofis. Semakin banyak kita bergantung padanya, semakin banyak pula masalah yang harus ditangani. Bahkan untuk memakainya dengan tenang pun semuanya sudah terlalu kusut—VSCode, Emacs, Nix, Vim, Firefox, JS, Node, semua plugin dan paket dependensinya saling terbelit. Karena itu, dengan agak memalukan saya makin mendekati kesimpulan aneh bahwa hanya dengan kertas dan teknologi yang minimal, benar-benar sederhana, saya baru bisa mendapat sedikit rasa kontrol atau keamanan. Saya tahu ini tidak rasional, tapi saya semakin muak dengan kompleksitas ini. Sekarang saya bahkan merasa sudah mencapai batas kompleksitas saya

  • Emacs sendiri aman dan semua ekstensinya pun bisa diaudit langsung. Tapi jika semua ekstensi diperbarui secara otomatis dan buta seperti konfigurasi Nix, masalah akan muncul. Kita juga bisa membayangkan otomatisasi yang memakai LLM untuk mendeteksi dan menyaring eksploit yang jelas. Jawaban sebenarnya untuk verifikasi skala perusahaan adalah memverifikasi semuanya secara formal dengan Coq, tetapi itu berarti membuang 99.999% software yang ada sekarang

• Di halaman manual xargs ada peringatan berbunyi “xargs tidak bisa digunakan dengan aman”. Namun isu keamanan ini berbeda dari kasus yang diterapkan di sini. Dalam kasus ini, cukup tambahkan -- di akhir untuk menghindarinya

• Kalimat “xargs tidak bisa digunakan dengan aman” sering disalahpahami. Misalnya, jika dijalankan sebagai cat "$HOME/changed_files" | xargs -r editorconfig-checker --, masalah spesifik yang dibicarakan di sini bisa diatasi

  • Tapi ini seperti mencegah XSS dengan menambahkan <div>{escapeHtml(value)}</div> satu per satu pada setiap nilai HTML. Jika Anda harus menerapkan cara aman secara manual di semua tempat, berarti pendekatannya memang salah sejak awal
  • Memang benar peringatan itu tidak sepenuhnya tepat untuk situasi ini, tetapi secara semantik umum tetap benar. Tidak semua program mendukung pemisah argumen seperti --, dan sebagian besar penggunaan xargs rentan terhadap injeksi argumen. Bisa dibilang ini sama seperti semua eksekusi command yang pada dasarnya berisiko. Ini bukan salah xargs sendiri, melainkan masalah realitas bahwa tool dipakai berulang dalam berbagai konteks izin

• Artikel itu punya celah fatal yang berdampak jauh lebih luas: dalam kode PR, file OWNERS bisa diubah menjadi symlink untuk mengekspos file arbitrer seperti file kredensial github actions. Karena git mendukung commit softlink, hampir workflow apa pun bisa terkena risiko seperti ini

  • Benar, tetapi kalau saya ingat dengan tepat, saat pull_request_target dijalankan, kredensialnya berasal dari repo target, yaitu repo yang menjadi tujuan merge. Jika dijalankan pada pull_request, kredensialnya berasal dari repo sumber yang dikendalikan penyerang

• Satu-satunya kabar yang “baik” adalah OpenBSD dan NetBSD masih memakai CVS untuk manajemen paket sehingga tidak terdampak kerentanan ini. Saya tidak yakin dengan FreeBSD. Keamanan, dalam arti tertentu, adalah efek dari penyamaran. Namun tampaknya proyek-proyek itu juga sedang mempertimbangkan migrasi ke git, dan OpenBSD sepertinya akan menuju got(1)

  • Benar juga, tetapi ini bukan kerentanan git melainkan kerentanan github actions. BSD aman secara tidak langsung karena github tidak mendukung CVS. Jika hanya memakai git atau github dan tidak memakai github actions, tidak akan terdampak
  • Ini bukan masalah git, melainkan isu yang spesifik pada github, dan github actions
  • Bukankah mereka menerima kontribusi lewat email? Kalau begitu, bukankah justru bisa lebih rentan terhadap serangan penyamaran?