macOS’in izin açılır pencerelerine güvenilebilir mi?

• CVE-2025-31250, macOS’teki TCC izin onayı açılır pencerelerini güvenilmez hâle getiren bir zafiyetti; ekranda görünen uygulama ile gerçekten izin alan uygulamanın farklı olmasını mümkün kılabiliyordu
• Sorun tccd içindeki TCCAccessRequestIndirect işleme mantığındaydı; target_path açılır pencerede gösterilecek uygulama adı için, target_identifier ise gerçekten izin alacak uygulama tanımlayıcısı için kullanılıyordu
• Önceki atlatma yöntemlerindeki gibi sahte uygulama, Dock kısayolu veya kullanıcıyı tıklamaya yönlendirme gerekmiyordu; kullanıcı sahte açılır pencerede Allow düğmesine bastığında saldırı gerçekleşebiliyordu
• Apple bunu macOS Sequoia 15.5’te yamaladı; ancak aynı gün çıkan Ventura 13.7.6 ve Sonoma 14.7.6’yı yamalamadı ve önceki sürümler için de yama planı olmadığını doğruladı
• Saldırganlar FaceTime, Voice Memos, System Settings gibi uygulamaların açıldığı anları hedefleyerek izin açılır penceresi sahteciliği deneyebilir; bu da kullanıcının iznin gerçekte hangi hedefe verildiğini yanlış anlaması riskini doğurur

---

CVE-2025-31250’nin temel işleyişi

• CVE-2025-31250, macOS TCC izin açılır penceresinde gösterilen uygulama ile gerçekten izin alan uygulamanın farklı olabilmesini sağlayan bir zafiyetti
• Yama öncesinde şu tür bir yapı mümkündü
  • Application A, macOS’ten izin onayı açılır penceresi göstermesini ister
  • Açılır pencere Application B’den gelmiş gibi görünür
  • Kullanıcının onay sonucu Application C’ye uygulanır
• Üç uygulama birbirinden farklı olabiliyordu; normal kullanımda ise genellikle aynı uygulama olmaları beklenir
• Temel sorun, açılır pencerede gösterilen uygulama ile gerçekten izin alan uygulama farklı olduğunda doğrulamanın yeterli olmamasıydı

Yamanın kapsamı ve düzeltmeler

• İlk açıklamanın aksine yama yalnızca macOS Sequoia 15.5’e uygulandı
• Aynı gün yayımlanan macOS Ventura 13.7.6 ve macOS Sonoma 14.7.6 yamalanmadı
• Sonoma 14.7.6 sanal makinesinde PoC derlenip çalıştırıldığında zafiyetin hâlâ işlediği görüldü
• Apple Product Security rapor durumunu “We’ve addressed the issue in all planned releases.” olarak değiştirdi ve daha sonra Ventura ile Sonoma için bu zafiyete yönelik yama planı olmadığını doğruladı
• Sonuç olarak Ventura ve Sonoma bu zafiyete açık durumda kalıyor

TCC ile Apple Events’in kesiştiği nokta

• TCC, Apple işletim sistemlerinin temel izin sistemidir ve dahili olarak tccd daemon’ı ile private TCC framework’ü üzerinden çalışır
• Geliştiriciler private API’leri doğrudan çağırmaz; ancak public API’ler ihtiyaç duyulduğunda dahili olarak TCC işlevlerini çağırır
• tccd, mesaj almak için Apple’ın XPC API’sini kullanır
• Yama öncesinde tccd’ye XPC mesajı gönderebilen bir uygulama, manipüle edilmiş bir mesaj göndererek izin açılır penceresinde gösterilen uygulama ile gerçekten izin alan uygulamayı ayırabiliyordu

Apple Events ve TCC veri modeli

• Apple Events, macOS’in süreçler arası iletişim yöntemidir ve günümüzde çoğunlukla otomasyon amacıyla kullanılır
• Apple Events otomasyonu, Apple’ın Open Scripting Architecture üzerinden betik hâline getirilebilir
  • Başlıca dil AppleScript’tir
  • JavaScript de kullanılabilir
• macOS Mojave 10.14’ten itibaren bir uygulamanın Apple Events gönderebilmesi için TCC üzerinden kullanıcı onayı gerekir
• TCC’nin kullanıcı onayı sonuçları, kullanıcının home klasörü altındaki Application Support/com.apple.TCC/TCC.db SQLite veritabanında saklanır
• Tipik bir TCC satırında istekte bulunan uygulama, istenen servis ve kullanıcı onayı sonucu bulunur
• Apple Events, izinleri alıcı uygulama bazında sınırlamak zorunda olduğundan indirect object sütununu kullanır
  • Bu sütunda Apple Events’i alacak uygulamanın tanımlayıcısı yer alır
  • Apple Events dışında FileProviderDomain servisi de bu sütunu kullanır

Zafiyetli XPC mesaj yapısı

• Sorun TCCAccessRequestIndirect fonksiyonundaki bir mantık hatasından kaynaklanıyordu
• Bu fonksiyon, TCC.db içindeki indirect object sütununu kullanması gereken erişim isteklerini işler
• PoC’nin özü, target_prompt değeri 2 olduğunda iki alanı ayrıştırarak yerleştirme yöntemiydi
  • target_path: GUI izin açılır penceresinde gösterilecek uygulama adını elde etmek için kullanılır
  • target_identifier: gerçekten veritabanına yazılan ve izin alan uygulamanın bundle ID’si olarak kullanılır
• TCCAccessRequestIndirect indirect object için bir fonksiyon olmasına rağmen, indirect object olarak boş string verilip bu sütunu kullanmayan başka birçok TCC servisi için de kullanılabiliyordu
• Bu hata diğer erişim isteği fonksiyonlarında yoktu

Kötüye kullanım koşulları ve sınırlamalar

• Zafiyetin kötüye kullanılması, kullanıcının izin açılır penceresinde Allow düğmesine basmasıyla başarılı olur
• Kullanılabilecek TCC servisleri sınırlıydı; ancak Microphone ve Camera gibi önemli servisler dahildi
• Belirli dizinlere erişim izni açılır pencereleri de sahte gösterilebiliyordu; ancak dosyalar etrafındaki ek güvenlik katmanları nedeniyle kullanışlılığı daha düşüktü
• Kötü amaçlı bir uygulamanın izni kendisine değil başka bir uygulamaya uygulatması da mümkündü
  • Bu, saldırganın başka bir uygulamayı kontrol edebildiği ancak o uygulamanın TCC iznine ihtiyaç duyduğu durumlarda kullanılabilecek bir yoldu

Açılır pencere zamanlamasını kullanarak kandırma

• İzin açılır penceresi rastgele bir anda belirirse kullanıcı şüphelenip Don’t Allow düğmesine basabilir
• macOS uygulamaları çalışan uygulamalar listesini ve o anda en öndeki uygulamayı kontrol edebilir
  • Çalışan uygulamaları kontrol etme: NSWorkspace runningApplications
  • En öndeki uygulamayı kontrol etme: NSWorkspace frontmostApplication
• Kötü amaçlı uygulama, belirli bir uygulama başlatılana veya en öne gelene kadar bekleyip ardından o uygulamanın adıyla sahte bir izin açılır penceresi gösterebilir
• Örneğin FaceTime başlatıldığında Camera izin açılır penceresi, Voice Memos başlatıldığında Microphone izin açılır penceresi sahte olarak gösterilebilir
• Kullanıcı, bir uygulamayı açtıktan veya ona geçtikten hemen sonra beliren açılır pencereyi o uygulamanın normal izin isteği sanabilir

Mevcut TCC atlatma yollarıyla bağlantı

• Daha önce tccd, kullanıcı home klasörünü HOME ortam değişkenine göre belirlediği için sahte home klasörü ve sahte TCC.db yerleştirme yöntemiyle TCC atlatılabiliyordu
• Bu sorun 2020 Temmuz ortası güncellemesinde yamalandı ve sonrasında tccd, home klasörünü işletim sisteminin kullanıcı bilgi dizininden sorgulamaya başladı
• Daha sonra kullanıcı home klasörünün değiştirilmesini kötüye kullanan başka atlatma örnekleri de görüldü
  • Wojciech Reguła, macOS’in GUI kullanıcı bilgi dizini düzenleyici eklenti sistemini kötüye kullanan CVE-2020-27937 zafiyetini yayımladı
  • Microsoft Threat Intelligence ekibi, import/export komutlarını kullanan powerdir atlatmasını yayımladı
• Kullanıcı home klasörünü değiştirmek için genellikle iki şey gerekir
  • root yetkisi
  • Belirli bir TCC servisi için kullanıcı onayı
• CVE-2025-31250, root yetkisi gereksinimini atlatamaz; ancak gereken TCC onayını sahte açılır pencereyle almaya yönlendirebilir
• Kötü amaçlı bir uygulama kullanıcıyı kandırarak onay alır ve root yetki yükseltmesini de elde ederse, kullanıcı bilgi dizinini değiştirip sahte TCC.db yerleştirme yolu mümkün olur
• REG.db geçerli TCC.db dosyalarını izler; ancak TCC’de uygulamaların REG.db’ye kayıt ekleyebilmesini sağlayan bir fonksiyon bulunduğundan, yerleştirilen TCC.db yolu eklenebilir

Kullanıcıya görünen izin yönetiminin sınırları

• TCC, System Settings içindeki Privacy & Security panelinin arkasında çalışan bir sistemdir
• Apple Events ile ilgili onay sonuçları Automation bölümünde gösterilir
• Privacy & Security panelinde kullanıcı verdiği onayları görebilir ve çoğu durumda belirli onayları geri alabilir
• Ancak saldırgan kullanıcıyı kandırarak Apple Events iznini onaylatmışsa, ilgili onay sonucu System Settings’te görünmüyordu
• Kullanıcılar tccutil CLI aracıyla onayı geri alabilir; ancak bu aracın dokümantasyonu sınırlıdır ve çoğu kullanıcının bunu bilmesi zordur
  • Apple belgeleri olarak eski bir Technical Q&A ve IT training page bulunur

Endpoint Security ve tespit olasılığı

• Apple’ın Endpoint Security framework’ü yakın zamanda TCC veritabanı değişikliklerini izlemeyi desteklemeye başladı
• Objective-See’nin yazısı bu değişikliği ele alan bir kaynaktır: Endpoint Security TCC database monitoring
• Bu özellik beklendiği gibi çalışırsa, framework’ü kullanan uygulamalar kullanıcıya sonradan gerçekte hangi uygulamaya izin verdiğini bildirebilir
• Ancak bu tespit olasılığı, Apple’ın Endpoint Security olayını eklediği zaman ile zafiyetin yamalanması arasındaki kısa dönem için doğrudan anlam taşıyordu

Apple’ın düzeltme yöntemi

• macOS Sequoia 15.5’teki tccd binary’sinin analizi, nihai yamanın ilk tahmin edilenden daha karmaşık olduğunu gösterdi
• Yama sonrasında aynı yöntemle TCC açılır penceresini sahte göstermek mümkün değil
• Indirect object’e boş string koyarak başka TCC servislerinde TCCAccessRequestIndirect kullanma davranışının da sınırlandığı görülüyor
• Zafiyetli biçimdeki mesajların artık tccd tarafından sessizce atıldığı ve hiçbir işlem yapılmadığı gözlemlendi
• Basit doğrulamada iyi bir yama gibi görünse de, tüm davranışı tam olarak anlamak için ek analiz gerekiyor

Raporlama ve yamaya kadar olan süreç

• Bu zafiyet Apple’a bildirilen ikinci hataydı ve Apple’ın yamaladığı raporlar arasında yamaya kadar en uzun süren örnekti
• Raporlama süreci; ilk bildirim, Apple Product Security’nin ek açıklama talebi, olası tam TCC atlatma yolunun paylaşılması, PoC test güncellemeleri, yeniden üretilebilirlik durumunun doğrulanması ve birkaç kez durum sorgulamasını içeriyordu
• Önerilen basit yama, iki alanın aynı uygulamayı işaret edip etmediğini doğrulama yöntemiydi
• Apple birkaç kez incelemenin sürdüğü yanıtını gönderdi; daha sonra teşekkür bölümünde kullanılacak adı istedi ve ardından yamayı yayımladı
• Zafiyete “TCC, Who?” adı verildi