Araştırma özeti

Eresus Security, FreeBSD TTY altyapısındaki TIOCSTI davranışını incelerken, düşük ayrıcalıklı bir sürecin kendi denetleyici terminali üzerinden daha ayrıcalıklı bir ön plan oturumunun girdisini etkileyebilmesine ilişkin bir risk belirledi.

Bu değerlendirme, paylaşılan bir terminal bağlamında çalışan güvenilmeyen arka plan süreçlerinin, ayrıcalıklı etkileşimli oturumlar için oluşturabileceği riske odaklanır. Araştırma; kullanıcı etkileşimiyle çalışan yerel bir senaryoda, terminal girdi sınırı ile ön plan işlem grubunun ayrıcalık seviyesi arasındaki ilişkinin yeterince doğrulanmadığını gözlemledi.

Bu yayın, savunma ve sistem yöneticilerinin risk değerlendirmesi içindir. Çalıştırılabilir PoC, komut dizisi veya istismar adımı içermez.

Sorumlu açıklama zaman çizelgesi

Şubat 2026: Eresus Security, teknik bulgu, etki analizi, olası geçici önlemler ve minimal PoC ile FreeBSD güvenlik ekibine koordineli açıklama talebi gönderdi.
Mayıs 2026: Yanıt alınamaması üzerine takip iletisi gönderildi.
14 Temmuz 2026: İlk bildirim üzerinden 90 günden fazla süre geçtiği için bu sınırlı, savunma odaklı kamuya açıklama yayımlandı.

Araştırmacı, ilk bildirim ve takip iletisi için doğrudan yanıt almadığını belirtmektedir. FreeBSD'nin kendi bildirim sayfası, işletim sistemi güvenlik sorunlarının güvenlik ekibine iletilmesini, bildirimin açıklama–etkilenen sürümler–geçici önlemler–gerekirse PoC içermesini ve ekip ya da bir temsilcinin geri dönüş yapmasını beklediğini belirtir.

Araştırma yaklaşımı: terminal durumunu ve yetki sınırını birlikte izlemek

Bu araştırma, TIOCSTI çağrısının tek başına kullanılabilir olup olmadığı sorusundan değil, terminalin o anda hangi süreç grubuna girdi teslim ettiği sorusundan başladı. TTY kodunda çağıranın denetleyici terminaliyle ilişkisi, dosya tanıtıcısının okuma yönü ve arka plan işlem kuralları incelendi; bunlar gerekli kontrollerdir fakat ayrıcalıklı ön plan süreciyle ilişkiyi tek başlarına açıklamaz.

İnceleme daha sonra üç durumu karşılaştırdı: çağıran sürecin kendi terminali olması, çağıranın ön planda veya arka planda bulunması ve ön plandaki süreç grubunun ayrıcalık düzeyi. Özellikle arka plan kuralının sinyale ilişkin davranışı, değerlendirmede belirleyici oldu. Bu, "ioctl var mı?" seviyesinden "bu karakteri sonunda hangi ayrıcalıktaki süreç okuyacak?" seviyesine geçmeyi sağlar.

Doğrulama, temiz bir test ortamında yapılan kontrollü davranış gözlemi ile kaynak kodu incelemesini birlikte kullandı. Yayında çalıştırılabilir komutlar, payload veya PoC yer almıyor; çünkü sistem yöneticisinin ihtiyacı istismar üretmek değil, paylaşılan terminal bağlamını ve ayrıcalıklı oturum alışkanlıklarını denetlemektir.

Kapsam, güven düzeyi ve sınırlar

Araştırma FreeBSD 14.4-RELEASE aarch64 üzerinde doğrulandı; ilk raporda ayrıca bildirimin verildiği tarihte incelenen CURRENT kaynak ağacındaki ilgili denetimin bulunmadığı kayda geçirildi. Bu, tüm donanım mimarilerinde aynı operasyonel sonucun ölçüldüğü veya upstream'in bugün hâlâ aynı durumda olduğu anlamına gelmez. Yayın tarihindeki sürüm ve upstream durumunu ayrıca kontrol etmek gerekir.

Risk yereldir ve paylaşılan TTY bağlamına dayanır. Ağ üzerinden tek başına erişim veren bir açık olarak sunulamaz. Buna rağmen geçici sudo yetki penceresi, kök kabuklar ve güvenilmeyen arka plan süreçleri bir araya geldiğinde etki ciddi olabilir. Bu sınırlar, doğru önceliklendirme yapmak ve müşteriye neyin gerçekten doğrulandığını açıkça anlatmak için burada özellikle belirtilmiştir.

Teknik etki, yüksek seviyede

TIOCSTI, bir terminalin giriş kuyruğuna karakter yerleştirebilen eski bir TTY arayüzüdür. Araştırmada incelenen koşulda, çağıran sürecin kendi denetleyici terminaline erişmesi tek başına yeterli görülürken, aynı terminalin ön plan işlem grubunda daha yüksek ayrıcalıklı bir işlem bulunup bulunmadığı ayrıca değerlendirilmemişti.

Bu sınıf sorun, sıradan TTY erişimi ile ayrıcalıklı bir kabuk ya da yönetim komutunun aynı terminal bağlamını paylaştığı ortamlarda önem kazanır. Risk değerlendirmesi; ayrıcalıklı kabuk oturumları, geçici sudo yetkilendirme pencereleri ve güvenilmeyen arka plan süreçlerinin bulunduğu iş akışlarına odaklanmalıdır.

Neden ön plan işlem grubu güvenlik açısından belirleyicidir?

Terminal, tek bir kullanıcının ekranı gibi görünse de çekirdek düzeyinde birden çok süreç arasındaki girdi/çıktı ilişkisidir. Denetleyici terminal bilgisi, çağıranın aynı TTY ile bağlantısını anlatır; fakat girdi tüketicisinin kim olduğunu anlatmaz. Ön plan işlem grubu ise kullanıcının yazdığı veya terminal kuyruğuna düşen karakterleri o anda hangi programın okuyacağını belirleyen bağlamdır.

Bu ayrım ayrıcalık sınırında önem kazanır. Düşük ayrıcalıklı bir süreç kendi terminaliyle ilişkili olabilir, ancak aynı terminalin ön planında daha yüksek ayrıcalıklı bir kabuk ya da yönetim komutu çalışıyor olabilir. Güvenlik kontrolünün yalnızca "bu senin terminalin mi?" sorusuna cevap vermesi, "bu girdi sonunda kimin komut bağlamına ulaşacak?" sorusunu yanıtsız bırakabilir. Araştırmanın tasarım dersi budur: kaynak nesneye sahiplik kontrolü ile güvenlik etkisini taşıyan tüketicinin yetki kontrolü aynı şey değildir.

Bu aynı zamanda başka yerel ayrıcalık değerlendirmeleri için kullanılabilir bir inceleme çerçevesidir. IPC kanalları, GUI mesaj kuyrukları, paylaşımlı soketler veya job-control mekanizmalarında; yazan tarafın nesneye erişimi, okuyan tarafın güvenlik bağlamı ve aradaki zamanlama birlikte değerlendirilmelidir.

Düzeltme tasarımında hangi özellikler korunmalı?

Sağlam bir düzeltme, yalnızca tek bir PoC davranışını engellemek yerine politika sınırını açıkça tanımlamalıdır. Bu vakada iki savunma yaklaşımı mantıklıdır: çağıranın ön plan tüketicisine göre uygun ayrıcalıkta olduğunu denetlemek veya TIOCSTI kullanımını varsayılan olarak kısıtlayan, yöneticinin bilinçli olarak açabileceği bir sistem politikası sunmak. İkinci yaklaşım, farklı eski uygulamaların davranışını etkileyebileceği için uyumluluk ve güvenlik arasındaki tercihi görünür kılar.

Bir upstream düzeltmesi değerlendirildiğinde test planı yalnızca olumsuz senaryodan oluşmamalıdır. Beklenen yetkili davranışlar, terminal emülatörleri, çoklu oturum araçları, job-control ve farklı sinyal yapılandırmaları regresyon açısından incelenmelidir. Amaç eski bir arayüzü körlemesine kapatmak değil, düşük ayrıcalıklı yazanın daha yüksek ayrıcalıklı tüketiciye etki etmesini engellerken meşru iş akışlarını ölçülü biçimde korumaktır.

Operasyonel görünürlük ve olay incelemesi

Bu risk için tek bir kusursuz log satırı beklenmemelidir. Savunma ekibi; ayrıcalıklı etkileşimli oturumların nerede kullanıldığını, sudo kullanımının hangi hostlarda yoğunlaştığını, kullanıcı süreçlerinin aynı PTY içinde nasıl başlatıldığını ve güvenilmeyen yazılımların bu oturumlarla birlikte çalışıp çalışmadığını envantere bağlamalıdır. Endpoint telemetrisi varsa beklenmedik TTY ioctl davranışları, yeni arka plan süreçleri ve ayrıcalıklı komut geçmişi zaman ilişkisi açısından değerlendirilmelidir.

Bir şüpheli olayda amaç, araştırmadaki senaryoyu tekrar oynatmak değil, etkilenmiş oturumları ve kimlikleri hızlıca sınırlamaktır. İlgili kullanıcı/host bağlamı korunur, ayrıcalıklı kimliklerin geçerliliği gözden geçirilir, operasyon kayıtları tutulur ve farklı oturumlarda yeniden kullanım riski değerlendirilir. Bu yaklaşım teknik doğruluğu korurken olay müdahalesini uygulanabilir tutar.

Bu durumun gerçek etkisi; kullanılan FreeBSD sürümüne, terminal topolojisine, yerel süreç denetimine, sudo yapılandırmasına ve kuruluşun ayrıcalıklı işlem prosedürlerine bağlıdır.

Güncel upstream durumu: sürümünüzü doğrulayın

FreeBSD kaynak ağacının güncel değişiklik kaydı, 9 Haziran 2026 tarihinde TIOCSTI'yi küresel olarak devre dışı bırakmaya yönelik bir sysctl seçeneği ekleyen ve ardından bunu security.bsd.allow_tiocsti adına taşıyan değişiklikleri listeliyor.

Bu değişiklik, yayın zamanındaki risk azaltımı açısından önemlidir. Ancak bu yazı, değişikliğin belirli bir rapora atfedildiğini veya tüm desteklenen sürümlere geri taşındığını iddia etmez. Sistem yöneticileri kullandıkları dal ve sürümde ilgili değişikliğin mevcut olup olmadığını, seçeneğin varsayılanını ve etkin yapılandırma değerini kendi sürüm notları ile kaynak ağacı üzerinden doğrulamalıdır.

Önerilen geçici önlemler

Güncelleme planı tamamlanıncaya veya kullanılan sürümdeki azaltım doğrulanıncaya kadar aşağıdaki kontroller riski düşürmeye yardımcı olur:

Ayrıcalıklı işlemler için güvenilmeyen süreçlerle paylaşılmayan ayrı PTY oturumları kullanın.
Sudo kimlik doğrulama önbelleği ve etkileşimli yönetim akışlarını kurum politikanıza göre gözden geçirin.
Özellikle paylaşılan geliştirme ya da yönetim sistemlerinde yerel süreç çalıştırma izinlerini en az ayrıcalık ilkesiyle sınırlayın.
Kullanılan FreeBSD dalında TIOCSTI küresel devre dışı bırakma kontrolünün varlığını ve etkin değerini doğrulayın.
Terminalle ilişkili ayrıcalık olaylarını izleme ve olay müdahalesi kayıtlarına dahil edin.

Eresus Guard ile kontrol kanıtı

Eresus Guard, DAST, SAST, SCA, IaC ve secrets değerlendirmelerini kanıt odaklı bir iş akışında birleştirir. Bu tür bir araştırma için ekipler; etkilenen varlıkları envantere bağlayabilir, yapılandırma ve ayrıcalık kontrollerini kayda alabilir, düzeltme kararını takip edebilir ve tekrar doğrulama kanıtlarını saklayabilir.

Amaç yalnızca bir bulguyu kapatılmış işaretlemek değildir; ilgili terminal, kimlik ve ayrıcalık varsayımlarının hangi sürümde ve hangi yapılandırmayla doğrulandığını tekrar incelenebilir hâle getirmektir. Eresus Guard çalışma alanını inceleyebilir veya kapsam görüşmesi planlayabilirsiniz.

Önceliklendirme: hangi sistemlere önce bakılmalı?

Her FreeBSD sunucusunda aynı maruziyet yoktur. İlk inceleme sırası, yalnızca sürüme değil terminalin nasıl kullanıldığına da dayanmalıdır. Paylaşılan bastion host'lar, birden çok geliştiricinin aynı makineye eriştiği build sistemleri, operasyon ekiplerinin düzenli olarak sudo kullandığı yönetim sunucuları ve üretim erişimi olan jump host'lar önceliklidir.

Bu sistemlerde aşağıdaki üç sinyal birlikte değerlendirilmelidir:

Aynı kullanıcı oturumunda güvenilmeyen veya az güvenilen süreç çalıştırılabiliyor mu?
Yöneticiler etkileşimli terminal üzerinden ayrıcalıklı iş yapıyor mu?
Kullanılan FreeBSD dalında TIOCSTI için güncel azaltım mevcut ve aktif mi?

Üç sorudan ikisine "evet" yanıtı çıkan sistemler, yalnızca rutin patch döngüsünü beklememeli; yapılandırma doğrulaması ve işlem ayrıştırması için önceliklendirilmelidir.

48 saatlik savunma doğrulama planı

İlk gün, sürüm envanteri ile terminal iş akışlarını eşleştirin. Hangi ekiplerin hangi hostlara SSH ile bağlandığını, sudo kullanım modelini ve ortak oturum araçlarını belgeleyin. İkinci gün, kullanılan dalda ilgili sysctl azaltımının varlığını ve etkin ayarını doğrulayın; ardından ayrıcalıklı işlemler için ayrı PTY, daha kısa kimlik bilgisi önbelleği veya ek operasyon onayı gibi kontrolleri değerlendirin.

Bu çalışma sırasında amaç hassas bir saldırı senaryosunu yeniden üretmek değildir. Amaç, aynı terminal bağlamına hangi süreçlerin erişebildiğini ve güven sınırlarının hangi denetimlerle korunduğunu kanıtlayabilmektir. Çıktı; etkilenen host listesi, sahip ekip, mevcut sürüm, doğrulanan kontrol ve kapatma tarihi içeren denetlenebilir bir kayıt olmalıdır.

Sık sorulan sorular

Bu yalnızca root shell kullanan ekipleri mi etkiler?

Hayır. Risk, ayrıcalıklı etkileşimli işlem ile düşük ayrıcalıklı sürecin terminal bağlamını paylaşmasına bağlıdır. Bu nedenle yönetim komutları, sudo tabanlı operasyonlar ve paylaşılan yönetim host'ları ayrıca gözden geçirilmelidir.

Sudo önbelleğini kapatmak tek başına yeterli mi?

Bu, belirli iş akışlarındaki riski azaltabilir; ancak terminal izolasyonu, sürüm/ayar doğrulaması ve en az ayrıcalık ilkesiyle birlikte ele alınmalıdır. Tek bir ayarı evrensel çözüm kabul etmek doğru değildir.

Eresus Guard bu çalışmada neyi somutlaştırır?

Guard; envanter, yapılandırma kanıtı, sorumlu ekip, düzeltme kararı ve yeniden doğrulama kaydını aynı akışta tutmaya yardımcı olur. Böylece "kontrol edildi" ifadesi, sürüm ve kanıtla desteklenebilen bir kapanış kaydına dönüşür.

FreeBSD TIOCSTI: Terminal Girdi Enjeksiyonu ve Yerel Ayrıcalık Riski