GitLab’da Haziran ayında kapatılan bir güvenlik açığı için çalışan bir istismar kanıtı yayımlandı. Güncellemeyi almamış self-managed GitLab kurulumlarında, doğrulanmış bir kullanıcının komutları git hesabı altında çalıştırabildiği belirtiliyor.
24 Temmuz’da yayımlanan PoC, GitLab 18.11.3 çalışan ve yamalanmamış sistemleri hedef alıyor. Saldırganın yönetici yetkisine, CI erişimine ya da kurban etkileşimine ihtiyacı yok; projeye push yetkisi olan herhangi bir kimlik doğrulanmış kullanıcı zinciri başlatabiliyor.
Jupyter not defteri önizlemesinden belleğe uzanan zincir
Araştırmacının ortaya koyduğu senaryoda saldırgan, özel hazırlanmış bir Jupyter not defteri projeye ekliyor ve commit diff görünümünü açıyor. Bu adım, bellekten bir heap işaretçisi sızdırıyor. Yeterli sayıda sızıntı toplandığında otomatik bir tarama süreci, uygulama belleğinde gerekli kütüphanelerin yerini bulabiliyor.
Ardından ek iki not defteri daha çalıştırılarak yük devreye sokuluyor. Saldırı zinciri, GitLab’ın depo içi bileşeni olan ipynbdiff üzerinden ilerliyor; bu bileşen, depodaki .ipynb JSON içeriğini uzun ömürlü Puma işçisi içinde Oj::Parser.usual.parse fonksiyonuna aktarıyor. Böylece saldırganın kontrol ettiği baytlar, uygulama sürecinin içindeki Oj’nin C seviyesindeki elle yönetilen bellek alanına ulaşıyor.
Teknik açıklamada iki ayrı bellek bozulması hatasının birlikte kullanıldığı aktarılıyor. İlk hata, sabit 1.024 baytlık iç içe geçme yığınını aşarak parser’ın start geri çağırma işlevinin denetimini ele geçiriyor. İkinci hata ise 65.565 baytlık bir nesne anahtarını imzalı 16 bitlik alanda 29’a kırpıyor ve canlı bir heap işaretçisi döndürüyor. GitLab bu sızıntıyı diff görünümünde kullanıcıya yansıtıyor; ardından elde edilen bilgi libc adresini bulmakta, yazma kısmı ise geri çağırma işlevini system() fonksiyonuna yönlendirmekte kullanılıyor.
Yama güvenlik değil, bug fix olarak geçti
GitLab’ın 10 Haziran’da yayımladığı düzeltme, güvenlik yaması olarak işaretlenmedi. İncelemede, Oj kütüphanesinin 3.17.3 sürümüne yükseltmenin yama notlarında bug fix başlığı altında yer aldığı, güvenlik düzeltmeleri tablosunda ise görünmediği belirtildi. Bu nedenle ortada bir CVE numarası, CVSS skoru ya da notebook-diff zincirine dair bir güvenlik duyurusu bulunmuyor.
Haziran 10 sürüm notunu güvenlik tablosuna göre tarayan operatörlerin, güncellemeyi acil bir düzeltme olarak görmesi için bir işaret yoktu. GitLab tarafından yayımlanan platform sürümlerine bakıldığında, etkilenen aralıklar CE ve EE için 15.2.0 ile 18.10.7, 18.11.0 ile 18.11.4 ve 19.0.0 ile 19.0.1 olarak sıralanıyor. İlk düzeltilen sürümler ise sırasıyla 18.10.8, 18.11.5 ve 19.0.2.
Oj tarafında da 3.13.0 ile 3.17.1 arasındaki sürümlerin etkilendiği, 3.17.3 ile düzeltmenin geldiği aktarılıyor. 3.17.2 sürümünün aynı incelemeden başka düzeltmeler taşıdığı, ancak bu iki belleğe yazma ve bellek sızıntısı hatasını içermediği ifade ediliyor. Ruby’nin kendisi etkilenmiyor.
Self-managed kurulumlar, Helm ve Operator ayrıntısı
Etki tüm katmanlarda geçerli: CE ve EE, Free’den Ultimate’a kadar. Buna karşın düzeltme yalnızca desteklenen sürüm çizgilerine veriliyor. 15.2 ile 18.9 arasındaki kurulumlar, GitLab’ın security-maintained patch trains dışına düştüğü için geri port alamıyor; bu sistemlerin desteklenen bir sürüme taşınması gerekiyor. Yama yükleyemeyenler için GitLab ve araştırmacı tarafı herhangi bir geçici çözüm sunmuyor.
Kurulum tarafında bir başka ayrıntı daha öne çıkıyor. Helm veya Operator kullananlar, chart ya da Operator sürümüne değil, çalışan Webservice imajının içindeki GitLab sürümüne bakmak zorunda. Çünkü Puma orada çalışıyor ve hedeflenen bileşen de bu süreç.
Komutlar git hesabı altında çalışıyor. Bu hesap, Puma’nın arkasındaki uygulama kimliği olarak görev yapıyor ve sistemde ne kadar ileri gidilebileceği kurulumun nasıl izole edildiğine bağlı kalıyor. Erişim alanı içinde kaynak kodu, Rails secret’ları, servis kimlik bilgileri, CI/CD verileri ve uygulamanın konuşabildiği dahili servisler yer alıyor.
Yayımlanan açık istismarı GitLab 18.11.3 ve x86-64 mimarisi için hazırlanmış durumda. Araştırmacıların kullandığı gadget ofsetleri, register durumu ve jemalloc davranışı doğrudan bu imajdan alınmış; ayrıca kurtarılan kütüphane tabanı, Puma master yeniden başladığında değişebiliyor. Bu nedenle kod, başka bir hedefe doğrudan kopyalanıp yapıştırılabilecek bir paket olarak sunulmuyor.
Araştırmacılar, açıkların kendisinin genel nitelikte olduğunu; ancak istismarı başka bir ortama taşımak için gerçek emek gerektiğini söylüyor. Yeni bir iki işçili kurulumda bellek aramasının beş ila on dakika sürdüğü, daha uzun süredir çalışan sistemlerde bunun bir ila iki saate uzayabildiği aktarılıyor. Çalışmanın ayrıntılı dökümü de yayımlandı.
İncelemeye göre Oj hataları 21 Mayıs’ta rapor edildi, bakımcı 27 Mayıs’ta düzeltmeleri birleştirdi ve Oj 3.17.3 4 Haziran’da yayımlandı. GitLab zinciri 5 Haziran’da GitLab’a iletildi, 8 Haziran’da doğrulandı ve 10 Haziran’da yamalandı. Araştırmacı, sahada aktif sömürü gördüğünü söylemiyor; GitLab’ın RCE’yi bağımsız biçimde yeniden ürettiğini belirtiyor. Oj üzerinde yapılan daha geniş inceleme ayrıca dokuz CVE duyurusunu daha ortaya çıkardı, ancak bunların hiçbiri bu zincir değil.
GitLab’a, düzeltmenin neden güvenlik olayı olarak sınıflandırılmadığı ve bir CVE atanıp atanmayacağı soruldu. Araştırmacıya da istismarın başka sistemlere taşınabilirliği hakkında görüş istendi. Yanıtlar bekleniyor.