Öğrencinin GitHub Actions tarayıcısı sıfır sömürülebilir açık, kendisinde ise 12 hata buldu

Adelaide Üniversitesi'nde siber güvenlik lisans öğrencisi olan bir geliştirici, GitHub Actions için bir taint-analiz tarayıcısı geliştirdi, yaklaşık 200 açık kaynak repolarda çalıştırdı ve ardından her yüksek önem dereceli bulguyu elle inceledi. Yazarın dev.to'daki yazısına göre sonuç şuydu: doğrulanmış sıfır sömürülebilir açık — ve tarayıcının kendisinde on iki hata.

Araç nasıl çalışıyor

ghast adlı araç, saldırgan kontrollü girdileri — bir issue başlığını, bir yorum gövdesini, bir fork'un branch adını — bir workflow'a girdikleri yerden bu değerleri yorumlayan herhangi bir noktaya kadar takip ediyor. Bu zincirler tek bir adım içinde nadiren görünürdür: bir değer adım düzeyindeki environment variable'lardan geçip bir adım çıktısına, oradan aşağı akıştaki bir job'ın needs context'ine girebilir ve sonunda dört sekme ve iki job sonra bir shell komutuna ulaşabilir.

Yazar tek bir katı tasarım kısıtı koydu: GitHub'ın belgelenmiş azaltımı — güvenilmeyen değerleri environment üzerinden yönlendirmek ve okumayı tırnak içine almak — asla işaretlenmemeli. Platformun kendi önerdiği güvenli deseni raporlayan bir tarayıcı iki kez çalıştırılmaz.

Batch modunda ghast, workflow'ları GitHub API üzerinden okuydu ve bulguları sıraladı; beş dil corpus'u ve uzun kuyruklu bir taramayla birlikte yaklaşık 1,800 workflow dosyasını kapsadı. 67 orta ölçekli repoda yapılan ilk geçişte, 61 orta önem dereceli bulgu ortaya çıktı ve bunların 59'u tek bir kuraldan geldi. Bu dengesiz yoğunlaşma, yazarın kuralın normal davranışı tehlikeli olarak tanımladığından şüphelenmesine yol açtı ve GitHub belgelerinin kontrol edilmesi, kuralın platformun nasıl çalıştığı konusunda düpedüz yanlış olduğunu kanıtladı. Her yüksek önem dereceli sonucu gerçek kaynakla elle doğruladıktan sonra sayaç şu hale geldi: sıfır sömürülebilir hata ve dört gruba ayrılmış bir düzine tarayıcı kusuru.

Çok fazla eşleşen desenler

İlk grup sıradan tespit hatalarından oluşuyordu. rtk-ai/rtk'de, bir pull request başlığını doğru şekilde bir environment variable üzerinden aktarıp tırnak içine alan bir satır yüksek önem derecesiyle rapor edildi; çünkü "eval içinde" ve "komum konumunda" durumlarını tek bir boolean'a indiren bir dedektör, tırnak içine alınmış değişken atamasını komut adı sanmıştı — bunlar, tırnaklamaya bağlı olarak farklı yanıtları olan iki farklı sorudur.

elastic/kibana'da bir pull request head'i checkout edildikten sonra sabitlenmiş (pinned) bir CLI'ı global olarak kuran üretilmiş bir workflow işaretlendi; çünkü "npm install" üzerindeki substring eşleşmesi, checkout edilen ağacın çalıştırılacağını varsaymıştı. Yazarın belirttiği gibi, npm ci repodaki package dosyasındaki lifecycle script'lerini çalıştırırken, registry'den adıyla kurulan sabitlenmiş bir paket ağacı hiç okumaz — özdeş önekler, zıt güvenlik özellikleri.

İki örnek daha: sertleştirilmiş pipeline'ı, artifact adı "preview-tarballs" bir script dosya adıyla substring olarak eşleştiği için yüksek önemle işaretlenen vercel/next.js ve bir ./tmp alt dizinine yapılan artifact indirmesini, tüm göreli yolları reddeden bir izolasyon kontrolü güvensiz olarak niteleyen ant-design/ant-design.

Cevapları başka dosyalarda yaşayan durumlar

İkinci grup daha öğretici: analiz mantığının tam olarak yazıldığı gibi çalıştığı, ancak tek dosyalık bir bakışın asla doğru olamayacağı durumlar.

93.000 yıldızlı bir repo olan ruvnet/RuView, kubectl image güncellemesiyle sonlanan üç job'a yayılan altı sekme uzunluğundaki bir zincir üzerinden kritik 10.0 puanı aldı. Veri akışı gerçekti ve enjeksiyon biçimi gerçekti — git, refname'lerde dolar işaretine ve parantezlere izin veriyor — ancak workflow_run erişilebilirliği, farklı ve adlandırılmış bir workflow'un tetikleyicilerine bağlıydı ve bu tetikleyicilerin hepsi yazma erişimi gerektiriyordu. Düzeltme ghast'ı iki geçişli hale getirdi: herhangi birini analiz etmeden önce bir repodaki tüm workflow'ları ayrıştırmak.

huggingface/transformers, tam tersine yakın olduğu halde kritik bir "pwn request" olarak rapor edildi. Yorum tetiklemeli CI'sı bir yazar izin listesine bağlıyor ve merge commit'i tetikleyen yorumdan daha yeni olduğunda çalıştırmayı reddeden bir timestamps kontrolü çalıştırıyor. GitHub, bir job'ın needs zincirindeki herhangi bir şey atlandığında o job'ı atladığından, yukğıdaki kapı her aşağı akış job'ını koruyor — tarayıcının yalnızca her job'ın kendi koşulunu okuyarak gözden kaçırdığı bir gerçek.

Neden önemli

Güvenilmeyen GitHub Actions context'leri üzerinden enjeksiyon aktif bir tedarik zinciri saldırı sınıfıdır ve bunun için kullanılabilir açık kaynak tarayıcılara gerçekten ihtiyaç var. Bu yazı, neden zor inşa edildiklerini gösteriyor: workflow güvenlik semantiği dosyalar ve job'lar arasına yayılır, dolayısıyla tek dosyalık bir analizci yapısal olarak doğru olma kapasitesinden yoksundur ve iyi sertleştirilmiş projelere karşı üretilecek false positive'ler, geliştiricileri araçları görmezden gelmeye alıştırır.

Olumlu bir okuma da var. Buradaki her false positive, savunmaların — tırnaklı environment yönlendirmesi, sabitlenmiş action'lar, sparse checkout'ler, izole artifact yolları, kapılı bağımlılık zincirleri — gerçekten işlediği bir projedir. Ve her bulguyu elle doğrulama ve tek bir kuralın 61 sonuçtan 59'unu üretmesini bir koku olarak görme yöntemi, güvenlik araçlarının herkes ona güvenmeden önce nasıl değerlendirilmesi gerektiğine dair bir modeldir.