Dalam dunia pembangunan perisian, sistem penyepaduan dan pelaksanaan berterusan telah menjadi alat penting untuk mengekalkan kualiti dan keselamatan kod. Walau bagaimanapun, satu insiden keselamatan baru-baru ini yang melibatkan GitHub Actions mendedahkan kelemahan asas dalam cara sistem ini mengendalikan kod yang tidak dipercayai, mencetuskan perdebatan sengit dalam kalangan pakar keselamatan dan pembangun tentang keselamatan aliran kerja pembangunan moden.
Masalah pull_request_target
Isu teras berpusat pada pencetus pull_request_target GitHub, yang menurut pakar keselamatan pada dasarnya tidak selamat dari segi reka bentuk. Berbeza dengan pencetus pull_request yang lebih selamat, pull_request_target memberikan kebenaran baca/tulis repositori dan akses kepada rahsia secara lalai, walaupun ketika memproses permintaan tarik dari garpu yang tidak dipercayai. Ini mewujudkan situasi berbahaya di mana pelaku berniat jahat berpotensi mengeksploitasi kelemahan untuk mendapatkan akses tanpa kebenaran kepada kelayakan sensitif dan kandungan repositori.
Ini adalah contoh yang bagus tentang mengapa
pull_request_targetpada asasnya tidak selamat, dan mengapa GitHub mungkin sepatutnya memadamkannya terus.
Masalah ini diburukkan lagi dengan dokumentasi GitHub yang mengelirukan yang mencadangkan bahawa pull_request_target lebih selamat kerana ia berjalan dalam konteks cawangan asas dan bukan komit gabungan. Pakar keselamatan berhujah bahawa dokumentasi ini tidak bertanggungjawab kerana ia memberi implikasi bahawa pencetus memberikan perlindungan terhadap serangan pelaksanaan kod, sedangkan pada hakikatnya ia hanya menggalakkan pembangun untuk menyemak secara eksplisit kod yang dikawal oleh penyerang, seterusnya mewujudkan permukaan kerentanan tambahan.
Perbandingan Pencetus Utama GitHub Action:
pull_request: Berjalan dengan kebenaran terhad, tidak mempunyai akses kepada secrets secara lalai apabila memproses forkspull_request_target: Berjalan dengan kebenaran baca/tulis dan akses secret secara lalai, walaupun untuk PR fork
Cabaran Model Mental
Pembangun menghadapi cabaran besar apabila menulis aliran kerja CI/CD untuk permintaan tarik kerana mereka sentiasa perlu bertukar antara dua konteks keselamatan yang berbeza. Apabila menulis langkah ujian dan pengesahan, pembangun biasanya beroperasi di bawah andaian bahawa mereka menjalankan kod yang dipercayai dari pasukan mereka sendiri. Walau bagaimanapun, apabila memproses permintaan tarik luaran, aliran kerja yang sama sedang melaksanakan kod yang berpotensi berniat jahat dari sumber yang tidak diketahui.
Konflik model mental ini menjadi sangat berbahaya apabila aliran kerja perlu berintegrasi dengan infrastruktur dalaman untuk tugas seperti ujian menyeluruh atau menyemak perjanjian penyumbang. Kerumitan integrasi ini memudahkan untuk secara tidak sengaja mewujudkan kerentanan keselamatan di mana operasi istimewa berinteraksi dengan input yang tidak dipercayai. Situasi ini mewakili kes klasik ketidakselamatan yang didorong oleh insentif - pembangun perlu melaksanakan operasi yang munasabah pada sumbangan pihak ketiga, tetapi alat yang tersedia mencipta risiko yang tidak perlu.
Melampaui Pelaksanaan Kod Ringkas
Kerentanan keselamatan melangkaui serangan pelaksanaan kod ringkas. Dalam insiden ekosistem Nix, penyerang mendapati mereka boleh mengeksploitasi pautan simbolik dalam repositori git untuk membaca fail sewenang-wenangnya pada sistem pelari. Dengan menggantikan fail konfigurasi dengan pautan simbolik yang menunjuk kepada fail kelayakan GitHub, mereka boleh mengekstrak token pengesahan dengan akses baca/tulis kepada keseluruhan repositori.
Kerentanan pautan simbolik ini menjejaskan hampir mana-mana aliran kerja yang memproses sumbangan luaran, mewakili permukaan serangan besar-besaran yang diabaikan oleh ramai pembangun. Masalahnya bukan dengan git itu sendiri tetapi dengan cara sistem CI/CD mengendalikan kandungan repositori tanpa sempadan keselamatan yang betul. Malah aliran kerja yang tidak secara eksplisit melaksanakan kod dari permintaan tarik boleh terdedah kepada serangan manipulasi sistem fail ini.
Corak Kerentanan Biasa:
- Suntikan argumen melalui alat seperti xargs
- Serangan pautan simbolik yang membenarkan penelusuran sistem fail
- Peningkatan keistimewaan melalui pendedahan kelayakan
- Pemisahan tidak mencukupi antara pelaksanaan kod yang dipercayai dan tidak dipercayai
Kelemahan Reka Bentuk Asas
Pakar keselamatan menunjuk kepada isu yang lebih mendalam dalam cara sistem CI/CD moden mengendalikan pengesahan. Pendekatan semasa untuk mengeluarkan token pembawa kepada program yang dipercayai mewujudkan situasi yang berisiko secara semula jadi. Seperti yang dinyatakan oleh seorang pengulas, jika GitHub Actions menyediakan soket Unix istimewa atau akses ejen-ssh dan bukannya token mentalah, jenis kerentanan ini akan menjadi lebih sukar untuk dieksploitasi.
Masalah ini diburukkan lagi oleh alat seperti xargs, di mana halaman manual menyatakan secara eksplisit bahawa adalah mustahil untuk xargs digunakan dengan selamat dalam konteks tertentu. Walaupun menambah penentu argumen -- boleh mengurangkan beberapa risiko, ini memerlukan pembangun untuk sentiasa berwaspada tentang keselamatan - satu pendekatan yang telah berulang kali terbukti tidak mencukupi dalam amalan. Komuniti keselamatan membandingkan ini dengan keperluan untuk secara manual mengelak HTML di mana-mana sahaja untuk mencegah serangan XSS.
Langkah Mitigasi Segera:
- Lumpuhkan aliran kerja yang terdedah dalam tetapan GitHub Action
- Semak semua penggunaan pencetus pull_request_target
- Laksanakan sanitasi argumen yang betul
- Gunakan kebenaran minimum yang diperlukan
- Asingkan operasi yang dipercayai dan tidak dipercayai sepenuhnya
Bergerak ke Arah Penyelesaian
Komuniti keselamatan telah mencadangkan beberapa pendekatan untuk menangani isu-isu ini. Sesetengah pakar mengesyorkan untuk melumpuhkan sepenuhnya pull_request_target di seluruh organisasi, manakala yang lain memperjuangkan agar GitHub menyediakan token halus, sekali guna yang direka khusus untuk operasi selamat pada PR pihak ketiga. Terdapat konsensus yang semakin berkembang bahawa model kebenaran semua-atau-tiada semasa adalah tidak mencukupi untuk aliran kerja pembangunan moden.
Organisasi yang prihatin tentang kerentanan ini boleh mengambil tindakan segera dengan melawat tetapan organisasi GitHub mereka, navigasi ke Actions → General, dan melumpuhkan tindakan di semua repositori. Pendekatan butang panik ini memberikan perlindungan sementara sementara langkah keselamatan yang lebih kekal dilaksanakan. Untuk keselamatan berterusan, pembangun harus mengaudit aliran kerja mereka dengan teliti, meminimumkan kebenaran, dan memisahkan secara ketat operasi yang dipercayai daripada yang tidak dipercayai.
Perbincangan yang berterusan ini menyerlahkan ketegangan antara kemudahan pembangun dan keselamatan dalam pembangunan perisian moden. Memandangkan sistem CI/CD menjadi lebih penting kepada proses pembangunan, mencari keseimbangan yang betul antara fungsi dan keselamatan kekal sebagai cabaran mendesak untuk seluruh industri.
Rujukan: Pwning the Entire Nix Ecosystem