Trigger pull_request_target GitHub Picu Krisis Keamanan yang Berbahaya

Dalam dunia pengembangan perangkat lunak, sistem integrasi dan penyebaran berkelanjutan telah menjadi alat penting untuk menjaga kualitas dan keamanan kode. Namun, sebuah insiden keamanan baru-baru ini yang melibatkan GitHub Actions mengungkapkan kelemahan mendasar dalam cara sistem ini menangani kode yang tidak terpercaya, memicu perdebatan sengit di antara pakar keamanan dan pengembang mengenai keamanan alur kerja pengembangan modern.

Masalah pull_request_target

Inti permasalahan berkisar pada trigger pull_request_target milik GitHub, yang menurut pakar keamanan pada dasarnya tidak aman oleh desain. Berbeda dengan trigger pull_request yang lebih aman, pull_request_target secara default memberikan izin baca/tulis repositori dan akses ke rahasia (secrets), bahkan saat memproses pull request dari fork yang tidak terpercaya. Hal ini menciptakan situasi berbahaya di mana pelaku jahat berpotensi mengeksploitasi kerentanan untuk mendapatkan akses tidak sah ke kredensial sensitif dan isi repositori.

Ini adalah contoh bagus mengapa pull_request_target pada dasarnya tidak aman, dan mengapa GitHub mungkin seharusnya menghapusnya sama sekali.

Masalah ini diperparah oleh dokumentasi GitHub yang menyesatkan yang menyiratkan bahwa pull_request_target lebih aman karena berjalan dalam konteks cabang dasar (base branch) alih-alih commit penggabungan (merge commit). Pakar keamanan berargumen bahwa dokumentasi ini tidak bertanggung jawab karena memberi kesan bahwa pemicu tersebut memberikan perlindungan terhadap serangan eksekusi kode, padahal kenyataannya justru mendorong pengembang untuk secara eksplisit memeriksa kode yang dikendalikan penyerang, sehingga menciptakan permukaan kerentanan tambahan.

Perbandingan Trigger GitHub Action Utama:

• pull_request: Berjalan dengan izin terbatas, tidak memiliki akses ke secrets secara default saat memproses fork
• pull_request_target: Berjalan dengan izin baca/tulis dan akses secret secara default, bahkan untuk PR dari fork

Tantangan Model Mental

Pengembang menghadapi tantangan signifikan saat menulis alur kerja CI/CD untuk pull request karena mereka harus terus-menerus beralih di antara dua konteks keamanan yang berbeda. Saat menulis langkah-langkah pengujian dan verifikasi, pengembang biasanya beroperasi dengan asumsi bahwa mereka menjalankan kode tepercaya dari tim mereka sendiri. Namun, saat memproses pull request eksternal, alur kerja yang sama justru mengeksekusi kode yang berpotensi berbahaya dari sumber yang tidak dikenal.

Konflik model mental ini menjadi sangat berbahaya ketika alur kerja perlu berintegrasi dengan infrastruktur internal untuk tugas-tugas seperti pengujian end-to-end atau memeriksa perjanjian kontributor. Kompleksitas integrasi ini memudahkan terciptanya kerentanan keamanan secara tidak sengaja di mana operasi yang memiliki hak istimewa berinteraksi dengan input yang tidak terpercaya. Situasi ini mewakili kasus klasik ketidakamanan yang digerakkan oleh insentif - pengembang perlu melakukan operasi yang wajar pada kontribusi pihak ketiga, tetapi alat yang tersedia justru menciptakan risiko yang tidak perlu.

Melampaui Eksekusi Kode Sederhana

Kerentanan keamanan meluas jauh melampaui serangan eksekusi kode sederhana. Dalam insiden ekosistem Nix, penyerang menemukan bahwa mereka dapat mengeksploitasi tautan simbolis (symbolic links) dalam repositori git untuk membaca file arbitrer pada sistem runner. Dengan mengganti file konfigurasi dengan tautan simbolis yang menunjuk ke file kredensial GitHub, mereka dapat mengekstrak token otentikasi dengan akses baca/tulis ke seluruh repositori.

Kerentanan tautan simbolis ini memengaruhi hampir semua alur kerja yang memproses kontribusi eksternal, mewakili permukaan serangan yang sangat besar yang sering diabaikan banyak pengembang. Masalahnya bukan pada git itu sendiri, tetapi pada bagaimana sistem CI/CD menangani isi repositori tanpa batas keamanan yang tepat. Bahkan alur kerja yang tidak secara eksplisit mengeksekusi kode dari pull request dapat rentan terhadap serangan manipulasi sistem file ini.

Pola Kerentanan Umum:

• Injeksi argumen melalui tools seperti xargs
• Serangan symbolic link yang memungkinkan penelusuran sistem file
• Eskalasi privilege melalui paparan kredensial
• Pemisahan yang tidak memadai antara eksekusi kode terpercaya dan tidak terpercaya

Cacat Desain Mendasar

Pakar keamanan menunjuk pada masalah yang lebih dalam dalam cara sistem CI/CD modern menangani otentikasi. Pendekatan saat ini dalam menerbitkan token pembawa (bearer tokens) ke program tepercaya menciptakan situasi yang pada dasarnya berisiko. Seperti yang dicatat seorang komentator, jika GitHub Actions menyediakan akses soket Unix atau ssh-agent yang memiliki hak istimewa alih-alih token mentah, jenis kerentanan seperti ini akan jauh lebih sulit untuk dieksploitasi.

Masalah ini diperburuk oleh alat-alat seperti xargs, di mana halaman manualnya secara eksplisit menyatakan bahwa xargs tidak mungkin dapat digunakan dengan aman dalam konteks tertentu. Meskipun menambahkan pemisah argumen -- dapat mengurangi beberapa risiko, hal ini mengharuskan pengembang untuk terus waspada terhadap keamanan - sebuah pendekatan yang telah berulang kali terbukti tidak memadai dalam praktiknya. Komunitas keamanan membandingkan ini dengan kebutuhan untuk secara manual meng-escape HTML di mana-mana untuk mencegah serangan XSS.

Langkah-Langkah Mitigasi Segera:

1. Nonaktifkan workflow yang rentan di pengaturan GitHub Action
2. Tinjau semua penggunaan trigger pull_request_target
3. Implementasikan sanitasi argumen yang tepat
4. Gunakan izin minimal yang diperlukan
5. Pisahkan operasi tepercaya dan tidak tepercaya sepenuhnya

Bergerak Menuju Solusi

Komunitas keamanan telah mengusulkan beberapa pendekatan untuk mengatasi masalah ini. Beberapa pakar merekomendasikan untuk sepenuhnya menonaktifkan pull_request_target di seluruh organisasi, sementara yang lain menganjurkan GitHub untuk menyediakan token khusus sekali pakai yang dirancang khusus untuk operasi aman pada PR pihak ketiga. Muncul konsensus yang berkembang bahwa model izin semua-atau-tidak-sama-sekali saat ini tidak memadai untuk alur kerja pengembangan modern.

Organisasi yang khawatir tentang kerentanan ini dapat segera mengambil tindakan dengan mengunjungi pengaturan organisasi GitHub mereka, menavigasi ke Actions → General, dan menonaktifkan actions di semua repositori. Pendekatan tombol panik ini memberikan perlindungan sementara sementara langkah-langkah keamanan yang lebih permanen diimplementasikan. Untuk keamanan berkelanjutan, pengembang harus mengaudit alur kerja mereka dengan cermat, meminimalkan izin, dan secara ketat memisahkan operasi tepercaya dari yang tidak tepercaya.

Diskusi yang sedang berlangsung ini menyoroti ketegangan antara kenyamanan pengembang dan keamanan dalam pengembangan perangkat lunak modern. Seiring sistem CI/CD menjadi lebih integral dalam proses pengembangan, menemukan keseimbangan yang tepat antara fungsionalitas dan keamanan tetap menjadi tantangan mendesak bagi seluruh industri.

Referensi: Pwning the Entire Nix Ecosystem