GNU strip'te yeniden oluşturulan trusting-trust saldırısı yapay zekâ kod incelemesinden görünmez kalıyor

Araştırma ne gösteriyor

Cole Halton'ın dev.io'daki yazısı, Ken Thompson'ın klasik trusting-trust saldırısını genişleten güncel bir makaleye (arXiv 2607.24888) dikkat çekiyor. Thompson'ın özgün gösterimi, ele geçirilmiş bir derleyicinin, derlediği programlara — kendi yeni kopyalarına bile — kaynak kodda şüpheli hiçbir şey görünmeden sessizce arka kapılar yerleştirebileceğini ortaya koymuştu.

Yazıya göre yeni sonuç, bu saldırı sınıfının hiç de derleyicilere özgü olmadığı. Araştırmacılar bunu, kaynak kodu ne okuyan ne de üreten, yalnızca elle oynanmış, bitmiş ELF binary'leriyle çalışan bir build aracı olan GNU strip ile gerçekleştirdi.

NixOS bootstrap'i içinde nasıl yayılıyor

Gösterim NixOS bootstrap sürecini hedefliyor. Yazıya göre, binary seed içine yerleştirilen tek bir kötü niyetli strip binary'si, bir sonraki strip nesline yayılan bir payload yerleştiriyor. Arka kapı, onu taşıyan seed build'den çıkarıldıktan sonra bile nihai standart ortamda varlığını sürdürüyor — özgün derleyici senaryosunu bu kadar ürkütücü kılan da aynı kendini sürekli kılma özelliğiydi.

Sonuç olarak ele geçirme işleminin depoya hiç dokunması gerekmiyor. Saldırı, bağımlılık zincirinin içinde hazır bir çalıştırılabilir dosya olarak geliyor.

Yapay zekâ incelemesi neden göremiyor

Yapay zekâ kod incelemesi yapan ya da satın alan herkes için en ilgi çekici kısım burası. Bu sistemler patch'i ve çevresindeki kaynak kodu okuyor. Yazarın belirttiğine göre hiçbiri build yolunu veya binary seed'i incelemiyor. Kötü niyetli mantık kaynak kodda hiç bulunmadığı için, o diff'i değerlendiren en güçlü akıl yürütme modeli bile değişikliğin temiz olduğu sonucuna varacaktır.

Yazarın argümanı, bunun bir yetenek eksikliği değil yapısal bir kör nokta olduğu. Aynı girdilere bakan daha büyük ya da daha akıllı bir model de aynı temiz pull request'i görür; sorun, aracın neye baktığında değil, ne gösterildiğindedir.

Sürekli birbirine karıştırılan iki soru

Yazı, birbirinden ayrı iki işin rutin olarak tek bir iş gibi ele alındığını savunuyor. İlki, bir kaynak kod değişikliğinin hata veya kusur getirip getirmediğine karar vermek — ve yazar bu alanda yapay zekâ incelemesini gerçekten ve şaşırtıcı biçimde etkili buluyor. İkincisi, kullanıcıların gerçekte çalıştırdığı artefaktın incelenen kaynak koda karşılık gelip gelmediğini doğrulamak — bu, diff tabanlı hiçbir incelemenin, ister insan ister model olsun, olumlu yanıtlayamayacağı bir soru. Bu iş artefakt provenance'ına ve build tekrarlanabilirliğine aittir.

Yapay zekâ incelemesini benimseyen ekipler için öneri bu ayrımdan doğrudan çıkıyor: Onu ilk iş için kullanın ve onayının ikinci işin yerine geçmesine izin vermeyin. Kabul eşiği bir modelin diff'e onay vermesinden fazlasına dönüşürse, kurum Thompson'ın tarif ettiği güven sorununu çözmüş olmaz — sorunu yalnızca derleyiciden başka bir build aracına taşımış ve zafer ilan etmiş olur.

Neden önemli

Bu sonuç üç açıdan önemli. Birincisi, trusting-trust tarzı ele geçirmelerin bilinen saldırı yüzeyini derleyicilerin ötesine, sıradan build araçlarına genişletiyor ve binary bootstrap seed'lerinin tüm bir dağıtım için güven çapası görevi gördüğünü gösteriyor: seed'deki tek bir kötü araç, NixOS'un nihai standart ortamına kadar kalıcı olabiliyor.

İkincisi, şirketlerin yapay zekâ incelemesini giderek artan biçimde kalite ve güvenlik kapısı olarak devreye aldığı bir dönemde geliyor. Artık bu kapının yapısal olarak kör olduğu somut ve kanıtlanmış bir arka kapı kategorisi var ve yazı, modelleri ölçeklemenin bu açığı kapatmayacağını açıkça belirtiyor.

Üçüncüsü, savunma çalışmasının nereye ait olduğunu yeniden çerçeveliyor: kaynak diff'lerin derinlemesine incelenmesine değil, provenance doğrulamasına, tekrarlanabilir build'lere ve binary seed'lerinin denetlenmesine.