GNU Screen'de keşfedilen birden fazla güvenlik sorunu

• GNU Screen 5.0.0 ve setuid-root kurulumu için ciddi güvenlik açıkları bulundu
• Başlıca sorunlar arasında yerel root yetki yükseltme, TTY ele geçirme ve herkes tarafından yazılabilir PTY oluşturulması yer alıyor
• Çok sayıda Linux ve UNIX dağıtımı kısmen ya da tamamen etkileniyor
• Geçici yamalar sağlandı ve birçok dağıtımda öncelikli müdahale gerekiyor
• Screen'in setuid-root tasarımının kendisinde temel güvenlik riskleri bulunuyor

---

1. Giriş

• Temmuz 2024'te Screen'in upstream geliştiricisi bir kod inceleme talebi iletti ve bununla birlikte güvenlik incelemesi başladı
• Daha önce kayda değer bir sorun bulunmamış olsa da bu kez Screen 5.0.0'da setuid-root yapılandırmasında ciddi bir root yetki yükseltme açığı tespit edildi
• Ek olarak, önceki sürümleri de (4.9.1 vb.) etkileyen bir dizi daha hafif güvenlik açığı doğrulandı
• Rapora sürüme göre açık yama setleri (4.9.1, 5.0.0) eklendi
• Dağıtıma göre Screen yapılandırması ve sürümü, başlıca açıklar, setuid-root ile ilgili geliştirme riskleri, güvenlik güçlendirme önerileri, açıklama koordinasyonu sürecindeki sorunlar ve etki matrisi gibi bilgiler yer alıyor

2. Screen yapılandırması ve sürüm özeti

• Ağustos 2024'te Screen 5.0.0 yayımlandı ve Arch Linux, Fedora 42, NetBSD 10.1 içinde yer aldı
• 5.0.0 çok sayıda refactoring içeriyor ve bunların bir kısmı 10 yıldan daha eski koda dayanıyor
• Bazı açıklar 5.0.0 ile yeni eklendi, bazıları ise önceki sürümlerde de (4.9.1 vb.) zaten mevcuttu
• Dağıtımların çoğunda hâlâ 4.9.1 kullanılıyor
• Screen çok kullanıcılı modu yalnızca setuid-root olarak kurulmuşsa kullanılabiliyor ve kod karmaşıklığı nedeniyle güvenlik saldırı yüzeyini ciddi biçimde büyütüyor
• Başlıca dağıtımlar arasında Arch Linux, FreeBSD, NetBSD Screen'i setuid-root olarak kuruyor; Gentoo'da ise yalnızca “multiuser” USE flag ile setuid-root kurulumu mümkün

3. Güvenlik sorunlarının ayrıntıları

3.a) logfile_reopen() üzerinden yerel root elde etme (CVE-2025-23395)

• Screen 5.0.0 setuid-root olarak çalıştırıldığında logfile_reopen() işlevi yetkileri düşürmeden kullanıcı girdisi yolunda dosya oluşturuyor
• Saldırgan, root sahipliğinde rastgele dosyalar oluşturup terminal verisini kaydedebilir ve bunu kötüye kullanabilir
• Mevcut dosyalar da istismar edilebilir; örneğin ayrıcalıklı shell script'lere kod ekleme gibi saldırılar mümkün
• Arch Linux, NetBSD 5.0.0 tamamen savunmasız; Fedora ve Gentoo'nun bazı ortamlarında ise kısmi etki var
• Yama, güvenli dosya işleme davranışının geri yüklenmesiyle uygulandı ve dağıtıma özgü somut etki farkları bulunuyor

3.b) Çok kullanıcılı oturuma bağlanırken TTY ele geçirme (CVE-2025-46802)

• Attach() işlevinde multiattach bayrağı etkin olduğunda TTY izinleri geçici olarak 0666 yapılıyor
• Bu süreçte bir yarış durumu (race condition) nedeniyle üçüncü bir kullanıcı ilgili TTY'ye okuma/yazma erişimi kazanabiliyor
• Girdi verisinin dinlenmesi, veri değiştirme ve parola hırsızlığı gibi riskler mevcut
• TTY izinlerinin eski haline döndürülmediği kod yolları da bulunuyor
• Yama, chmod 666 işleminin kaldırılmasıyla uygulandı; bazı yeniden bağlanma kullanım senaryoları bozulabilir ancak bunlar zaten daha önce de düzgün çalışmıyordu

3.c) PTY varsayılan izin açığı (CVE-2025-46803)

• 5.0.0'da PTY'nin varsayılan izinleri 0620 → 0622 (herkes yazabilir) olarak değiştirildi
• Bu, özellikle tüm kullanıcıların başka PTY'lere yazabilmesini mümkün kıldığı için potansiyel güvenlik riskini artırıyor
• Bu değişikliğin yanlışlıkla eklendiği düşünülüyor; yama, derleme sırasında güvenli varsayılanın (0620) geri yüklenmesiyle sorunu çözüyor
• Arch Linux, NetBSD başlıca etkilenenler arasında

3.d) Soket hata mesajları üzerinden dosya varlığı bilgisinin sızması (CVE-2025-46804)

• SCREENDIR ortam değişkeni ve Error mesajları kullanılarak gerçek bir dosya/dizinin varlığı root yetkisiyle doğrulanabiliyor
• Bu küçük çaplı bir bilgi sızıntısı ve tüm setuid-root kurulumlarında risk taşıyor

3.e) Sinyal gönderiminde TOCTOU yarış durumu (CVE-2025-46805)

• CheckPid() ile Kill() işlevleri arasındaki zaman farkı nedeniyle hedeflenmeyen bir PID'ye root yetkisiyle sinyal gönderilmesi riski var
• Çoğunlukla yalnızca SIGCONT, SIGHUP gibi sinyallere izin verildiği için etki sınırlı, ancak hizmet reddi (DoS) veya hafif bütünlük bozulması ortaya çıkabilir

3.f) Hatalı strncpy() kullanımı nedeniyle komut aktarımında taşma

• 5.0.0'da strncpy()'nin hatalı kullanımı nedeniyle tampon taşması ve program çökmesi meydana geliyor
• Düzgün yamanmazsa komut aktarımı sırasında MAXPATHLEN sonrasındaki bellek üzerine yazılarak hizmet dışı kalma durumuna yol açabilir
• Bu bir güvenlik sorunu değil, ancak kararlılık açısından hızlı düzeltme gerekiyor

4. setuid-root uygulamasına ilişkin ek riskler

• Çok kullanıcılı modda çoklu kullanıcı UID işleme mantığının zayıf olduğu görüldü
• setuid-root durumunda yetki düşürme mantığı tam değil
• Root tarafından oluşturulan oturumlarda etkili yetki düşüşü gerçekleşmediğinden genel risk seviyesi yüksek

5. Genel güvenlik güçlendirme önerileri

• Büyük ölçekli kod refactoring sürecinde mevcut güvenlik mantığının bozulduğu doğrulandı
• setuid-root ikili dosyaların doğası gereği güvenlik test paketi eklenmesi ve tüm dosya sistemi/ortam değişkeni işlemlerinin ihtiyatlı biçimde tasarlanması gerekiyor
• Özellikle setuid-root ile tam çalıştırma önerilmiyor; çok kullanıcılı özellik yalnızca güvenilen bir grubun opt-in yöntemiyle sınırlandırılmalı
• Ortam değişkenleri (PAH vb.) mutlaka yalnızca güvenilir yolları gösterecek şekilde zorlanmalı

6. Açıkların duyuru koordinasyonu sürecindeki sorunlar

• Upstream ile koordinasyon süreci verimsiz ilerledi ve bu da yama geliştirme ile açıklamanın gecikmesine yol açtı
• Upstream tarafında kodu anlama ve müdahale kapasitesinin yetersizliği nedeniyle yakın iş birliği zorlaştı
• Sonuçta yamaların geliştirilmesine dağıtım tarafı öncülük etti ve rapor planlanan takvime göre yayımlandı
• Screen projesinin kendisinde de bakım ve yönetim kapasitesi eksikliği görüldü

7. Etki matrisi

• Arch Linux (5.0.0, setuid-root): 3.a, 3.b, 3.c, 3.d, 3.e, 3.f tüm açıklar etkili
• Debian/Ubuntu dahil çok sayıda dağıtım: 3.b (kısmi etki)
• Fedora 42 (5.0.0, setgid-screen): 3.b (kısmi etki), 3.f etkili
• Gentoo (4.9.1, setgid-utmp): 3.b (kısmi etki), unstable ebuild + multiuser USE flag durumunda 5.0.0 ile aynı etki
• FreeBSD 14.2 (4.9.1, setuid-root): 3.b, 3.d, 3.e etkili
• NetBSD 10.1 (5.0.0, setuid-root): 3.a, 3.b, 3.c, 3.d, 3.e, 3.f etkili
• OpenBSD 7.7 (4.9.1): 3.b (kısmi etki)
• openSUSE TW: 3.b (kısmi etki)

8. Takvim

• 2024-07-01: upstream'ten kod inceleme talebi alındı
• 2025-01-08: inceleme başladı
• 2025-02-07: açıklar upstream'e gizli olarak bildirildi, koordineli açıklama talep edildi
• 2025-02~04: yama görüşmeleri sürdü, embargo dönemi sorunları nedeniyle takvim yeniden düzenlendi
• 2025-05-12: bu rapor ve resmî duyuru yayımlandı

9. Referans bağlantıları

• GNU Savannah [Screen proje sayfası]
• openSUSE Bugzilla, ilgili yamalar, ilgili CVE'ler, hata raporları ve belge bağlantıları dahil

[GN⁺]

Hacker News yorumu

• Birden fazla kullanıcının aynı anda bir oturuma bağlanmasına izin veren bir multi-user modu var; bu özelliğin tmate gibi araçları mümkün kıldığını düşünüyorum, tmux'ta da aynı zafiyetin olup olmadığını merak ediyorum
  • tmux Unix domain socket kullanıyor; screen'in neden setuid yaklaşımını kullandığını anlamıyorum, root yetkisi gerekmiyor gibi görünüyor; TFA'daki açıklamaya göre mevcut screen geliştiricileri kod tabanını tamamen kavrayamadığı için, işlevi kolayca hayata geçirmek adına setuid-root yaklaşımını seçmişler gibi görünüyor
  • Bu özellik gerçekten harika; eğitim oturumlarında her öğrenciye dizüstü bilgisayarımda kendi giriş hesabını verip ssh shell'ini screen -x <belirli kullanıcının penceresi> ile sınırlandırıyorum, böylece öğrenci yalnızca ilgili screen ACL'inde izin verilen pencereleri kullanabiliyor; ben de projektörle her öğrencinin ekranını tek tek kontrol edip gösteriyorum, ama güvenlik açıklarıyla dolu olması şaşırtıcı değil
  • screen -x komutunu kullanma deneyimim var
• Debian'da GNU screen, setuid root yetkisiyle kurulmuyor
  • Debian Stable (bookworm) paketi çok eski olduğundan 5.0.0 zafiyetinden etkilenmiyor; eskiden Debian'ın yazılım sürümlerinin çok yavaş olmasından hoşlanmazdım ama şimdi yalnızca gerekli birkaç uygulama için ayrı paket kaynaklarıyla yeni sürüm kullanıyor, diğerlerini ise eski sürümle de gayet iyi kullanıyorum
  • Gentoo'da da durum aynı, ancak Gentoo'da utmp grubuna SETGID atanmış; bunun ne anlama geldiğinden pek emin değilim
  • Slackware 15'te screen için suid yok
  • Fedora'da setuid ile kurulmuş gibi görünüyor
• Blog yazısının render edilmiş sürümü tanıtılıyor: https://security.opensuse.org/2025/05/12/screen-security-issues.html
• GNU Screen'in log dosyası kaydetme özelliğiyle ilgili belgeler yetersiz olduğu için yazara e-posta gönderdim; GNU'nun daha iyi bir issue tracking sistemine ihtiyacı olduğunu düşünüyorum, ilgili kaynak: http://www.zoobab.com/screenrc
  • tmux yazarıyla bir Soru-Cevap da vardı; 16 yıl önce de dokümantasyon eksikliğinden şikayet ediliyordu, ilgili kaynak: https://undeadly.org/cgi?action=article&sid=20090712190402
• Gözlemlenen davranış 2005'ten beri Screen'de vardı; bu antipattern uzun süre rkhunter gibi araçlarla örtüldü, 90'larda da screen'in setuid root olduğundan eminim
• upstream'in (resmi geliştirme ekibi) bu kez işin içinde olması şaşırtıcı; yaklaşık 5 yıl önce GNU screen geliştirmesinin tamamen durduğunu düşünüp üzülmüştüm, hâlâ öyle olup olmadığını merak ediyorum; ekrana attach olmadan screen'e yeni pencere ekleme özelliği olup olmadığını da merak ediyorum
  • upstream, inceleme talebini SUSE ekibine iletti; geliştirici kaynağı yetersiz ve şu anda bakımı iyi yapılmıyor gibi görünüyor, eğer öyleyse bu üzücü; tmux gibi alternatifler olsa da birçok kişi uzun süredir Screen kullanıyor, araçların yaşlanması üzücü
  • Dahil oldukları tek şey onu setuid-root olarak dağıtmak olmuş; yalnızca bu şekilde yapılandıran dağıtımlar zafiyetten etkileniyor, diğerleri etkilenmiyor; resmi yama yavaş kaldığında dağıtımlar doğrudan kendileri patch uyguluyor
  • GNU araç geliştirmesinin durmasının (bug fixler hariç) mutlaka kötü bir şey olduğunu düşünmüyorum; bu, özelliğin yeterince olgunlaştığının bir işareti olabilir
  • upstream ile iletişim zor olduğu için bug fix/sürüm yayınları hakkında ayrıntılı bilgiye sahip değilim; güvenlik incelemesi talep edildi ama iletişim kurmanın zor olduğu bir durum var gibi görünüyor
  • Açık kaynakta, bir yazılım sona erip yerine alternatif gelse bile hemen geçiş yapmak için yeterli teşvik oluşmaması nedeniyle bir atalet problemi var; tersine, sadece markayı satın alıp tamamen farklı bir şeye dönüştüren örnekler de çıkıyor (Audacity gibi), iyi bir çözüm yok
• Render edilmiş sürüm bağlantısı: https://security.opensuse.org/2025/05/12/screen-security-issues.html
• Kaç geliştiricinin popüler açık kaynak araçların hepsini gerçekten bizzat kullandığını ve bu araçları kullanan alanlarda ne kadar para döndüğünü merak ediyorum
• tmux'ın OpenBSD'nin varsayılan kurulumuna 4.6'dan beri dahil olduğunu hatırlıyorum ve denetimden geçti; güvenliğe daha fazla önem verenler için iyi bir alternatif
  • screen'den bahsedildiğini görünce, geçmişte tmux'a geçtikten sonra yanlışlıkla screen kullanmamaya alışıp kafamın karıştığını hatırladım
• screen ve setuid'in birlikte anılması ilginç; bir keresinde garip bir sorunu çözmek için screen'e chmod u+s vermiştim, böyle bir şey yapmak zorunda olmak tuhaf hissettirmişti; ama sonra screen'de setuid'e dayanan özellikler olduğunu ve bazı sistemlerin bunu varsayılan olarak böyle dağıttığını öğrendim; ayrıca u+s verince screen benim ~/.screenrc dosyam yerine root'un ~/.screenrc dosyasını okudu (bunu geçici bir çözüm olarak kabul ettim), screen'in her build'inde setuid desteği farklı olabilir diye düşünüyorum
  • setuid zaten özünde böyle çalışır; bir binary üzerinde özel bit ayarlarsanız, her zaman belirtilen kullanıcı olarak çalıştırılması anlamına gelir