Çok Sayıda Yeni macOS Sandbox Kaçış Açığı

 (jhftss.github.io)
1 puan yazan GN⁺ 2024-11-09 | 1 yorum | WhatsApp'ta paylaş
  • macOS sandbox kaçışı araştırmalarında nispeten daha az görülen PID domain XPC servisleri bir saldırı yüzeyi olarak ortaya çıktı ve 10’dan fazla yeni açığın keşfedilmesine yol açtı
  • Ana hedef, System/User domain’indeki Mach servisleri değil; uygulama veya framework yüklenirken PID domain’e kaydedilen Application türü XPC servisleri
  • Açık örnekleri arasında CVE-2023-27944, CVE-2023-32414, CVE-2023-32404, CVE-2023-41077, CVE-2023-42961, CVE-2024-27864, CVE-2023-42977 vb. yer alıyor; bazıları TCC bypass, SIP ile ilgili yetkiler ve iOS etkileriyle de bağlantılı
  • Tekrarlayan başarısızlık noktası, sandbox’a alınmamış servislerin dosya, dizin, arşiv ve DMG işlerken quarantine genişletilmiş özniteliğini, yol dizelerini ve istemci yetki doğrulamasını güvenli biçimde ele alamamasıydı
  • Apple’ın yanıtı, savunmasız XPC servislerinin kaldırılması, girdilerin normalize edilmesi, doğrulamanın sunucu tarafına taşınması ve private entitlement zorunluluğu getirilmesiyle sonuçlandı; ancak hâlâ yama bekleyen 5 rapor bulunuyor

macOS sandbox modeli ve kaçış hedefi

  • macOS’ta Apple’ın kendi servisleri ve üçüncü taraf uygulamalar dahil birçok süreç, kısıtlı bir sandbox ortamında çalışır
  • Saldırgan sandbox içindeki bir süreçte uzaktan kod yürütme (RCE) elde etse bile yürütme kabiliyeti ve dosya erişim izinleri sınırlı olduğundan, sonraki adım daha geniş yetkiler elde etmek için sandbox kaçışıdır

  • App Sandbox

    • Mac App Store gereksinimleri nedeniyle birçok uygulama App Sandbox kısıtlamalarıyla çalışır
    • Sandbox uygulamaları com.apple.security.app-sandbox entitlement’ına sahip olmalıdır
    • Kısıtlamalar, uygulamanın main fonksiyonundan önceki dyld başlatma aşamasında uygulanır
    • App Sandbox’a girildiğinde uygulama container’laştırılır ve dosya işlemleri veri container yolu ile sınırlandırılır
    • Sandbox uygulamasının oluşturduğu dosyalara varsayılan olarak com.apple.quarantine genişletilmiş özniteliği eklenir
    • Sandbox profilinde bu genişletilmiş özniteliğin kaldırılmasını engelleyen kurallar bulunur
    • App Sandbox’ın ayrıntılı izinleri /System/Library/Sandbox/Profiles/application.sb içinde tanımlıdır
    • Ağ, donanım, dosya sistemi ve erişilebilir Mach servisleri kısıtlanır
    • fork edilen alt süreçler ebeveynin App Sandbox kısıtlamalarını devralır
    • LaunchService.framework ile çalıştırılan süreçler kısıtlamaları devralmaz; örneğin sistem open komutuyla sandbox dışı bir uygulama doğrudan çalıştırılabilir

  • Service Sandbox

    • Apple’ın birçok daemon servisi Service Sandbox bağlamında çalışır
    • Servis sandbox profilleri çoğunlukla /System/Library/Sandbox/Profiles/*.sb ve /usr/share/sandbox/*.sb altında bulunur
    • Service Sandbox kısıtlamaları, servisin main fonksiyonunda sandbox_init_XXX API’si çağrılarak manuel uygulanır
    • Service Sandbox’a giren servisler genellikle container’laştırılmaz
    • Önemli fark, Service Sandbox içinde oluşturulan dosyaların varsayılan olarak quarantine’e alınmamasıdır
    • Quarantine ile ilgili API’ler manuel çağrılmazsa oluşturulan dosyalara quarantine eklenmez

Mevcut macOS sandbox kaçış yolları

  • LaunchService.framework saldırısı

    • Mevcut yaygın yöntemlerden biri, LaunchService.framework üzerinden sandbox dışı uygulamalara saldırmaktır
    • CVE-2021-30864, sistemdeki sandbox dışı Terminal.app uygulamasına karşı $HOME ortam değişkeninin manipüle edildiği bir örnektir
    • Terminal çalıştırıldığında, kontrol edilebilir $HOME/.profile altındaki zararlı payload sandbox kısıtlamaları olmadan çalışır
    • Bir diğer senaryo, yeni bir sandbox dışı uygulamayı bırakıp ardından çalıştırmaktır
    • Ancak sandbox uygulamasının yeni bıraktığı uygulama quarantine’e alındığı için çalıştırılması engellenir
    • Bir dosya veya klasör quarantine olmadan bırakılabilirse App Sandbox tamamen bypass edilebilir
    • CVE-2023-32364, devfs’in genişletilmiş öznitelikleri desteklememesinden yararlanarak quarantine’siz bir klasör bırakılan bir örnektir

  • Erişilebilir Mach servislerine saldırı

    • İkinci yaygın yöntem, App Sandbox profilinde listelenen Mach servislerine saldırmaktır
    • Sistemin Mach servis bilgileri /System/Library/xpc/launchd.plist içinde saklanır
    • bootstrap_look_up API’siyle sandbox uygulamasından belirli bir Mach servisine erişilip erişilemediği kontrol edilebilir
    • Bu tür Mach servisleri System domain veya User domain içinde bulunur
    • Bu araştırmanın çıkış noktası, App Sandbox’tan erişilebilen XPC servislerinin bu iki domain’in dışında da bulunduğudur

Yeni saldırı yüzeyi: PID domain XPC servisleri

  • Gözden kaçırılan XPC servisleri PID domain içinde bulunur
  • Genellikle incelenen System/User domain XPC servislerinden farklı olarak bunların servis türü Application’dır
  • Application türü XPC servisleri uygulama isteği üzerine çalıştırılır ve isteği yapan uygulama kapandığında onunla birlikte sonlanır
  • System/User domain’deki XPC servislerine sandbox uygulamalarından yalnızca application.sb içinde tanımlanmışlarsa erişilebilir
  • Uygulama ve framework’lerin ihtiyaç duyduğu tüm XPC servisleri ilgili uygulamanın PID domain’inde görünür
  • PID domain’deki birçok XPC servisi, sandbox uygulamalarından çağrılacağını öngörmediği için gelen XPC istemcilerinde entitlement kontrolü veya sandbox kontrolü yapmayabilir

  • SystemShoveService.xpc örneği

    • SystemShoveService.xpc, sistemdeki private ShoveService.framework içindeki bir XPC bundle’ıdır
    • Info.plist’teki servis türü Application, bundle tanımlayıcısı ise com.apple.installandsetup.shoveservice.system’dır
    • Sandbox uygulamasından /System/Library/PrivateFrameworks/ShoveService.framework yüklendiğinde karşılık gelen XPC servisi PID domain’e otomatik kaydedilir
    • SystemShoveService.xpc, istekte bulunan XPC istemcisini denetlemediği için App Sandbox kaçışı için kötüye kullanılabiliyordu
    • Bu servis, com.apple.rootless.install adlı güçlü bir SIP ile ilgili entitlement’a sahip olduğundan SIP korumasının bypass edilmesiyle de ilişkilendirilebiliyordu
    • İlgili açık CVE-2022-26712 olarak atandı; ayrıntılar önceki yazıda özetlenmiştir

  • Keşif yöntemi

    • Service Type’ı Application olan tüm XPC servisleri, App Sandbox kaçışı için potansiyel hedeftir
    • Sistem framework’lerinde ve private framework’lerde XPC servisleri listelenerek bulunabilir
      • /System/Library/Frameworks
      • /System/Library/PrivateFrameworks
    • Gelen XPC istemcisini denetlemeyen bir PID domain XPC servisi varsa şu yöntemlerle saldırı denenebilir
      • Quarantine olmadan bir uygulama klasörü bırakarak tam sandbox kaçışı elde etmek
      • Sandbox dışı uygulama içeren bir ZIP veya DMG dosyasını quarantine olmadan bırakmak

Yalnızca beta sürüme özgü 2 açık

  • Beta-No-CVE-1: StorageKit’te keyfi komut yürütme

    • Apple bu açığı additional recognitions bölümüne kaydetti, ancak CVE atamadı
    • Apple’a göre CVE yalnızca üretime yayımlanmış yazılımlardaki açıklara atanıyor; yalnızca beta yazılımdaki açıklara atanmıyor
    • Etkilenen hedef yalnızca macOS Sonoma Beta sürümleri
    • Açık barındıran XPC hizmetinin yolu /System/Library/PrivateFrameworks/StorageKit.framework/XPCServices/storagekitfsrunner.xpc
    • Bu hizmet sandbox kısıtlamaları olmadan çalışabiliyordu ve delegate metodunda tüm XPC istemcilerini kabul ediyordu
    • SKRemoteTaskRunnerProtocol’ün tek metodu olan runTask:arguments:withReply:, belirtilen yürütülebilir dosya yolu ve argümanlarla keyfi komut çalıştıracak şekilde tasarlanmıştı
    • Yürütülebilir dosya yolu ve argümanlar sandbox içindeki XPC istemcisi tarafından kontrol edilebildiği için, sandbox kısıtlamaları olmadan keyfi sistem komutu yürütmek mümkündü
    • Apple, macOS Sonoma 14.0 kararlı sürümü yayımlanmadan önce açık barındıran XPC hizmetini işletim sisteminden tamamen kaldırdı

  • Beta-No-CVE-2: AudioAnalyticsHelperService’te ZIP oluşturmanın kötüye kullanımı

    • Bu açığa da aynı yalnızca beta gerekçesiyle CVE atanmadı
    • Açık barındıran XPC hizmetinin yolu /System/Library/PrivateFrameworks/AudioAnalyticsInternal.framework/XPCServices/AudioAnalyticsHelperService.xpc
    • Hizmet sandbox kısıtlamaları olmadan çalışabiliyordu ve tüm XPC istemcilerini kabul ediyordu
    • createZipAtPath:hourThreshold:withReply: metodu, XPC istemcisinin belirttiği keyfi yolu sıkıştırıyordu
    • Belirtilen yolda compressed klasörü yoksa oluşturuyor, .json dosyalarını bulup bu klasöre taşıdıktan sonra ZIP dosyası oluşturuyordu
    • Saldırgan compressed klasörünü symlink ile değiştirerek keyfi dosyaları keyfi konumlara taşıyabiliyordu
    • Kaynak dosya içeriği denetlenmiyor; hedef dosya yolunun .json soneki taşıması gerekiyordu
    • Yeni oluşturulan ZIP dosyası, hizmet sandbox’a alınmadığı için quarantine işlemine tabi tutulmuyordu
    • Apple, macOS Sonoma 14.0 yayımlanmadan önce gelen XPC istemcisinin com.apple.audioanalytics.helper.service entitlement’ını kontrol edecek şekilde yama yaptı
    • Güncel macOS’te private AudioAnalyticsInternal.framework ve ilgili XPC hizmeti tamamen kaldırıldı

CVE-2023-27944: TrialArchivingService

  • Açık barındıran hizmet /System/Library/PrivateFrameworks/TrialServer.framework/XPCServices/TrialArchivingService.xpc
  • Bu hizmet /System/Library/Sandbox/Profiles/com.apple.trial.TrialArchivingService.sb profiliyle Service Sandbox içine giriyor
  • Service Sandbox olduğu için bırakılan dosyalar quarantine işlemine tabi tutulmuyor
  • Hizmet gelen tüm XPC istemcilerini kabul ediyor
  • extractArchiveFromHandle:withArchiveName:toDirectory:destDirExtension:postExtractionCompression:completion: metodu, sandbox içindeki uygulamanın ilettiği arşiv dosyasını belirtilen konuma çıkarıyor
  • Çıkarılan içeriğe quarantine genişletilmiş özniteliği aktarılmadığından, quarantine olmayan dosya bırakmaya yol açabiliyordu

  • Kötüye kullanım koşulları ve atlatma

    • Bu metot kötüye kullanıldığında, arşiv içindeki Mach-O dosyasının çıkarıldıktan sonra çalıştırma izni kayboluyor ve doğrudan çalıştırılamıyor
    • CVE-2021-30990 tekniğinde olduğu gibi symlink kullanmak bir atlatma yolu olabilir
    • Ancak bu XPC metodu yalnızca dizinleri ve normal dosyaları çıkarıyor; arşivden symlink çıkarılmasına izin vermiyor
    • Bir atlatma yöntemi, payload uygulamasını sandbox uygulama container yoluna çıkarmak
    • Sandbox uygulaması bu yolda okuma-yazma iznine sahip olduğundan doğrudan symlink oluşturabilir veya chmod ile çalıştırma izni verebilir
    • Başka bir yöntem payload uygulamasını iki kez arşivlemek
      • Açık barındıran XPC metoduyla dış ZIP’i açmak
      • Sistem open komutuyla iç ZIP’i açmak

  • Yama

    • Apple, macOS Ventura 13.3’te gelen XPC istemcisinin com.apple.TrialArchivingService.internal entitlement’ını kontrol edecek şekilde yama yaptı
    • İlgili entitlement yoksa XPC bağlantısını reddediyor

CVE-2023-32414: ArchiveService

  • Açık barındıran hizmet /System/Library/PrivateFrameworks/DesktopServicesPriv.framework/XPCServices/ArchiveService.xpc
  • Bu hizmet Service Sandbox içine giriyor, ancak bırakılan dosyalar quarantine işlemine tabi tutulmuyor
  • Hizmet tüm XPC istemcilerini kabul ediyor
  • unarchiveItemWithURLWrapper:… metodu, sandbox içindeki uygulamanın ilettiği öğeyi belirtilen konuma arşivden çıkarıyor
  • Çıkarılan içeriğe quarantine genişletilmiş özniteliğini aktarmadığı için, sandbox uygulaması quarantine olmayan keyfi dosyalar bırakabiliyordu
  • XPC istemcisi, DesktopServicesPriv.framework içindeki Objective-C sınıfı DSArchiveService’te zaten uygulanmıştı

  • Yama

    • Apple, macOS Ventura 13.4’te gelen XPC istemcisinin com.apple.private.ArchiveService.XPC entitlement’ını kontrol edecek şekilde yama yaptı
    • İlgili entitlement yoksa XPC bağlantısını reddediyor

CVE-2023-32404: ShortcutsFileAccessHelper

  • Açık barındıran hizmet /System/Library/PrivateFrameworks/WorkflowKit.framework/XPCServices/ShortcutsFileAccessHelper.xpc
  • Bu hizmet sandbox kısıtlamaları olmadan çalışabildiğinden App Sandbox kaçışı için kötüye kullanılabiliyordu
  • Kod imzasında Full Disk Access için özel TCC entitlement’ı da bulunuyordu
  • Bu nedenle açık, TCC korumasını tamamen atlatmak için de kötüye kullanılabiliyordu
  • Hizmet tüm XPC istemcilerini kabul ediyor
  • WFFileAccessHelperProtocol’ün tek metodu olan extendAccessToURL:completion:, XPC istemcisine keyfi URL için okuma-yazma izni verecek şekilde tasarlanmıştı
    • İçeride sandbox_extension_issue_file API’sini çağırarak dosya erişim token’ı veriyor
    • Keyfi URL, sandbox içindeki XPC istemcisi tarafından belirleniyor

  • Yama

    • Apple, macOS Ventura 13.4’te gelen XPC istemcisinin com.apple.shortcuts.file-access-helper entitlement’ını kontrol edecek şekilde yama yaptı
    • İlgili entitlement yoksa XPC bağlantısını reddediyor

CVE-2023-41077: mscamerad-xpc ve tekrarlanan yama atlatmaları

  • Güvenlik açığı bulunan servis /System/Library/Frameworks/ImageCaptureCore.framework/XPCServices/mscamerad-xpc.xpc idi
  • Bu servis sandbox kısıtlamaları olmadan çalışabildiği için App Sandbox’tan kaçışta kötüye kullanılabiliyordu
  • Kod imzasında, kullanıcı istemi olmadan Photos ve Removable Volumes’a erişebilen özel TCC entitlement’ları vardı
  • Bu nedenle söz konusu TCC koruması da aynı anda atlatılabiliyordu

  • Açık akışı

    • Varsayılan servis adı com.apple.mscamerad-xpc idi
    • Servis tüm XPC istemcilerini kabul ediyordu
    • ICXPCDeviceManagerProtocol içindeki openDevice:withReply: yeni bir MSCameraDevice açıp yapılandırıyordu
    • Yeni cihaz başlatılırken, kamera cihazına yönelik servis rutinleri sağlamak için başka bir anonim XPC servisi açılıyordu
    • Bu anonim XPC servisi de tüm XPC istemcilerini kabul ediyordu
    • ICCameraDeviceProtocol içindeki requestReadDataFromObjectHandle:options:withReply: metodu, istenen dosya öğesinin içeriğini okuyup XPC istemcisine döndürüyordu
    • İstenen dosya yolu XPC istemcisi tarafından kontrol edilebildiğinden, sandbox içindeki bir uygulama konteyner dışındaki rastgele dosyaları okuyabiliyordu
    • Servisin güçlü TCC entitlement’ları nedeniyle kullanıcının Photos verileri de kullanıcı istemi olmadan okunabiliyordu

  • Sahte kamera cihazı yapılandırması

    • MSCameraDevice, bir DMG dosyası oluşturup mount ederek emüle edilebiliyordu
    • DMG birimi içindeki dosya yolu belirli bir düzenli ifadeyle eşleşirse dosya öğesi ICCameraFile olarak indeksleniyordu
    • Klasör adı örnekleri: 123abcde, DCIM, dcIm
    • Dosya adı örnekleri: abcd1234.mp3, 1234E5678.HEIC
    • Sandbox içindeki bir uygulama, DMG dosyasını bırakıp açarak ve mount ederek sorunu tetikleyebiliyordu
    • XPC istemcisi ImageCaptureCore framework’ünde zaten uygulanmıştı

  • Yama ve atlatma

    • Apple, macOS Sonoma 14’te acceptConnection: içine yeni bir kontrol ekledi
    • İstemcide com.apple.private.imagecapturecore.authorization_bypass private entitlement’ı varsa izin veriyordu
    • Ya da istemci platform binary ise izin veriyordu
    • Platform binary koşulu, Apple imzalı bir ikiliye dinamik kütüphane enjekte edilebildiği için atlatılabiliyordu
      • Entitlement’ı olmayan Apple imzalı ikili /bin/ls seçildi
      • DYLD_INSERT_LIBRARIES ortam değişkeniyle önceki exploit kodunu içeren dylib enjekte edildi
      • Ardından önceki gibi XPC servisiyle iletişim kuruldu
    • Apple bu atlatma raporuna CVE-2024-23253 atadı
    • macOS 14.4’te ikinci koşul güçlendirildi; XPC istemcisinin yalnızca platform binary olması değil, ayrıca CS_REQUIRE_LV veya CS_FORCED_LV bayraklarıyla imzalanmış olması gerekiyordu
    • Bu yama da atlatılabiliyordu
      • /bin/ls içine dylib enjekte edildi
      • Çalışma zamanında csops API’siyle gerekli bayraklar elle ayarlandı
      • Ardından XPC servisi kontrolünden geçildi
    • Apple bu ikinci atlatmaya CVE-2024-40831 atadı
    • macOS Sequoia 15’te, yalnızca com.apple.private.imagecapturecore.authorization_bypass private entitlement’ına sahip XPC istemcilerine izin verecek şekilde yeniden yama yapıldı

CVE-2023-42961: intents_helper

  • Bu güvenlik açığı iOS’ta da kötüye kullanılabiliyor
  • Güvenlik açığı bulunan servis /System/Library/Frameworks/Intents.framework/XPCServices/intents_helper.xpc idi
  • Servis sandbox kısıtlamaları olmadan çalışabiliyor ve tüm XPC istemcilerini kabul ediyordu
  • filePathForImageWithFileName fonksiyonundaki path traversal (yol geçişi) nedeniyle rastgele yollara erişim mümkündü
  • fileName parametresi XPC istemcisinin kontrol edebildiği rastgele bir dizeydi

  • Etkilenen metotlar

    • Açıklı fonksiyona iki XPC metodu üzerinden ulaşılabiliyordu
    • retrieveImageWithIdentifier:completion: .png uzantılı rastgele dosyaları okumak için kötüye kullanılabiliyordu
    • Okunan veri, bir INImage örneğinin üye değişkenine kaydediliyor ve XPC istemcisine döndürülüyordu
    • purgeImageWithIdentifier:completion: rastgele dosya yollarını silmek için kötüye kullanılabiliyordu

  • Yama

    • Apple, macOS Sonoma 14.0’da XPC istemcisinden gelen giriş dizelerini normalleştirecek şekilde yama yaptı
    • Path traversal için kullanılan özel karakterleri kırpıyordu

CVE-2024-27864: diskimagescontroller

  • CVE kaydı, yazının hazırlandığı sırada yayımlanmayı bekliyordu
  • Güvenlik açığı bulunan servis /System/Library/PrivateFrameworks/DiskImages2.framework/XPCServices/diskimagescontroller.xpc idi
  • Bu servis, kod imzasında com.apple.diskimages.creator-uc entitlement’ına sahip olduğu için güçlü işlemler yapabiliyordu
  • Bu entitlement’ın başlıca iki işlevi vardı
    • FDA entitlement’ına sahip olan ve gerçek attach işlemini gerçekleştiren /usr/libexec/diskimagesiod ile iletişim kurmak
    • IOKit servisi AppleDiskImagesController’a bağlanarak DMG dosyaları için cihaz oluşturmak ve quarantine işlemi uygulamak

  • Açığın nedeni

    • Servis tüm XPC istemcilerini kabul ediyordu
    • DIControllerProtocol içindeki attachWithParams:reply: metodu saldırı noktasıydı
    • İçeride checkAttachEntitlementWithError çağrılıyordu; ancak bu fonksiyon adının aksine her zaman TRUE döndürüyordu
    • DiskImages2.framework içinde, XPC istemcisinin zaten uygulanmış olduğu Objective-C sınıfı DIAttachParams bulunuyordu
    • Framework’ün istemci kodu, giriş URL’sinin quarantine durumunda olup olmadığını kontrol ediyordu
    • Giriş URL’si quarantine durumundaysa attach öncesinde quarantine parametresini ayarlıyor; bu parametre XPC servisine hedef cihaza quarantine uygulamasını bildiriyordu
    • Kendi XPC istemcinizi oluşturduğunuzda quarantine parametresi ayarını atlayıp doğrudan attachWithParams:reply: çağrılabiliyordu
    • Bunun sonucunda quarantine’li bir DMG dosyası attach edilirken karşılık gelen cihaza quarantine uygulanmayabiliyordu

  • Yama

    • Apple, macOS Sonoma 14.4’te doğrulama mantığını istemci tarafından sunucu tarafına taşıdı
    • Giriş dosya yolu quarantine durumundaysa sunucu, karşılık gelen cihaza doğrudan quarantine uyguluyordu

CVE-2023-42977: PerfPowerServicesSignpostReader

  • Açık bulunan servis /System/Library/PrivateFrameworks/PowerlogCore.framework/XPCServices/PerfPowerServicesSignpostReader.xpc
  • Servis sandbox kısıtlamaları olmadan çalışabiliyor ve tüm XPC istemcilerini kabul ediyor
  • XPCSignpostReaderProtocol içinde 6 yöntem var, ancak Apple yalnızca submitSignpostDataWithConfig:withReply: yöntemini uygulamış; kalan 5 yöntem boş uygulanmış
  • Bu yöntemin temel mantığı, günlük verilerini toplayıp gzip dosyası olarak arşivlemek
  • XPC istemcisinin kontrol ettiği tagUUID dizesiyle powerlog yolu rastgele bir yola yönlendirilebiliyordu

  • Rastgele yol silme

    • Fonksiyon içinde archiveDirectoryAt:deleteOriginal: çağrılarak powerlog yolu siliniyor
    • TagUUID içine path traversal dizesi konursa rastgele yol silme primitive’i elde edilebiliyor

  • Rastgele dizin oluşturma ve tam sandbox kaçışı

    • createSignpostFile: fonksiyonu powerlog yolunda dizin oluşturuyor
    • Bu sayede quarantine genişletilmiş özniteliği olmayan rastgele bir dizin oluşturulabiliyor
    • Quarantine olmayan rastgele dizin oluşturma primitive’i tam sandbox kaçışına yol açabiliyor
    • Yazıda CVE-2023-32364 tekniği kullanılıyor
      • Quarantine olmayan bir .app klasörü oluşturuluyor
      • Contents/MacOS altında /bin/bash symlink’i oluşturuluyor
      • LSEnvironment içinde BASH_ENV ayarlanıyor
      • open ./poc.app ile çalıştırılıyor

  • Yama

    • Apple, macOS Sonoma 14.0’da XPC istemcisinin UUID dizesini normalize edecek şekilde yama yaptı
    • Girdi dizesi geçerli bir UUID değilse fonksiyondan çıkılacak şekilde işlendi

Tekrarlayan kalıp

  • Temel saldırı yüzeyi System veya User domain’deki XPC servisleri değil, sistem ve private framework’ler içindeki PID domain XPC servisleri
  • Service Type’ı Application olan XPC servisleri, yalnızca framework yüklenmesiyle sandbox’lı uygulamanın PID domain’ine kaydedilebiliyor
  • Açık bulunan servislerin çoğu sandbox istemcilerinden çağrı beklemediği için şu kontrolleri atlamıştı
    • XPC istemcisi entitlement kontrolü
    • İstemcinin sandbox’lı olup olmadığı kontrolü
    • Girdi yolu normalizasyonu
    • Sunucu tarafında quarantine durumu doğrulaması
  • Tekrar tekrar kötüye kullanılan koşullar şunlar oldu
    • Quarantine olmayan dosya/klasör bırakma, tam sandbox kaçışına yol açabiliyor
    • Arşiv açma sırasında quarantine genişletilmiş özniteliği kaybolursa Gatekeeper atlatmaya ve sandbox kaçışına yol açabiliyor
    • Service Sandbox’ın oluşturduğu dosyalar varsayılan olarak quarantine işleminden geçirilmiyor
  • Hâlâ yama bekleyen 5 rapor kaldı

App Sandbox ve Service Sandbox hakkında ek görüşler

  • Apple, bir rapor için yeni çalıştırılan uygulamanın mevcut süreç bağlamında olmadığını ve mevcut sürecin entitlement’larını veya izinlerini paylaşamayacağını belirterek bunun expected behavior olduğuna karar verdi
  • App Sandbox’ta bırakılan dosyalar varsayılan olarak quarantine işleminden geçirilir
  • Service Sandbox’ta bırakılan dosyalar varsayılan olarak quarantine işleminden geçirilmez
  • Yeni çalıştırılan sürecin mevcut servis yürütme bağlamında olmaması ve bu nedenle ilgili servisin entitlement’larını veya privilege’larını paylaşmaması başlı başına bir flaw değil diye özetleniyor
  • Buna karşılık saldırganın sandbox kısıtlamalı servis bağlamında RCE elde ettikten sonra yeni, sandbox’sız bir uygulama bırakıp çalıştırarak hedef servisin sandbox kısıtlamalarından çıkabilmesi flaw olarak görülebilir
    • Örnek olarak NSO Group’un 0-click exploit hedefi olan IMTranscoderAgent anılıyor
  • com.apple.WebDriver.HTTPService.xpc, WBSEnableSandboxStyleFileQuarantine API’sini manuel çağıran bir örnek olarak geçiyor
  • App Sandbox’tan Service Sandbox’a kaçmanın macOS’te fiilen Non Sandbox’a geçmek olduğu özetleniyor

İlgili okumalar

1 yorum

 
GN⁺ 2024-11-09
Hacker News yorumları

  • Burada XPC servislerini tek tek yamalayarak verilen tepki biraz garip görünüyor
    Bu daha çok sandbox’ın kendi tasarım sorunu gibi duruyor ve uygulama içi kullanım için tasarlanmış gibi görünen XPC servislerine sandbox’lı uygulamaların neden bu kadar çok erişebildiği soru işareti

    • Aynen. Bunun macOS’e sonradan eklendiğini düşünürsek, UNIX ve NeXTSTEP’ten gelen şeyleri bozmamak için yapılmış bir uzlaşma olması muhtemel
      Windows tarafında da WinRT sandbox’ı, Win32 uygulama sandbox’ı, güvenlik çekirdeği, sürücü koruması gibi benzer mekanizmalar var ama farklı yapılandırmalar arasında tek bir çalıştırılabilir dosya çalıştırmak istiyorsanız geriye dönük uyumluluğun açıkları ortaya çıkıyor
      Mobil işletim sistemlerinde geriye dönük uyumluluk yok ve yürütme modelini sıkı biçimde sınırlayabildikleri için iş çok daha kolay

  • macOS’un, dev bir engelleme listesi yığını gibi görünen bu yaklaşım yerine, capability tabanlı bir Darwin container benzeri yapıya sahip olması gerekirdi

  • İyi iş
    Yine de bu mimarinin doğru yön olup olmadığından emin değilim. Belirli bir saldırıyı engellemek için her güvenlik çerçevesi oluşturulduğunda tamamen yeni bir sorun sınıfı ortaya çıkıyormuş gibi geliyor ve sonunda daha güvenli hale geldiğimiz hissi oluşmuyor
    Hollanda vergi yasası gibi, istismarı önlemek için üst üste yama eklenmiş bir yapı ve belki de artık bilinç kazanmış olabilir

    • Bunun gibi sistemlerin önemli bir kısmı en baştan sona gerçekten güvenli olacak şekilde tasarlanmadı
      Doğru yaklaşım ise genellikle geriye dönük uyumluluk yüzünden ya da geliştiricilerin özellikleri benimsemeyi reddetmesi nedeniyle pazarda başarısız oluyor. WinRT sandbox’ı buna bir örnek
      Telefon güvenliği daha kolaydı çünkü geriye dönük uyumluluk gerekmiyordu ve şimdiye kadar App Store kapı bekçiliği sayesinde katılmak isteyen geliştiriciler kurallara uymak zorunda kaldı
    • Sonuçta güvenlik, geriye dönük uyumlulukla zor bağdaşır
      Bugün kullanılan tüm işletim sistemlerinin gelecek yüzyıla kadar güvenli kalabilmesi için en baştan yeniden yapılması ve bu süreçte çok sayıda kodun çöpe atılması gerekir. Bedeli bu
    • Hollanda vergi yasasına gönderme yapılması komik. O “istismar boşluklarının” bazılarının kasıtlı olarak bırakıldığını söyleseniz bile çok tartışma çıkmayabilir
      Tüketici bilişiminde de daha fazla açığı bilinçli olarak itmeye çalışan güçlü aktörler olabileceği tahmin edilebilir
      Her bir ünlü örnek şunlar
      https://en.wikipedia.org/wiki/Dutch_Sandwich
      https://en.wikipedia.org/wiki/Intel_Management_Engine#Assert...

  • macOS, yani NeXTstep, en başından beri açık ve son derece genişletilebilir bir işletim sistemi olarak tasarlanmıştı
    Üçüncü taraf genişletmeler veya hook’lar eklemenin sayısız yolu vardı ve yazılıma birden fazla runtime’dan erişilebildiği için o dönemde bütün bunların sorunsuz biçimde birlikte çalışması başlı başına etkileyici bir teknik başarıydı
    Java, klasik Mac, X11 ve NeXTstep kod tabanları, çekirdeğin çeşitli genişletme giriş noktaları sayesinde sorun yaşamadan birlikte çalışabiliyordu
    Ayrıca platformda uygulamaların birbiriyle sorunsuz iletişim kurmasını sağlayan API’ler de vardı
    Ama Apple yavaş yavaş bu felsefeden uzaklaştı ve sistemi giderek daha kapalı hale getiriyor. Oldukça ilginç bir yolculuk

  • SBPL (sandbox profile language) ilginç. Daha fazla ayrıntı burada: https://github.com/0xbf00/simbple
    macOS içinde bunu işleyen bir Scheme yorumlayıcısı bir yerlerde mi var diye merak ediyorum
    Not: Bunu yapan şey galiba sandbox-exec. Referans: https://reverse.put.as/wp-content/uploads/2011/09/Apple-Sand...

  • Etkileyici bir bulgu. Yazının da ima ettiği gibi, benzer kusurların hâlâ sahada bulunma ihtimali çok yüksek görünüyor
    Apple bu servisleri sertleştirme yaklaşımını yeniden tasarlamazsa, XPC ile ilgili CVE’ler düzenli olarak gelmeye devam edecek gibi

  • Sandbox’ı hem seviyorum hem sevmiyorum
    Harika bir ikinci savunma hattı, ama büyük kuruluşlar sandbox’tan çıkmadan anlamlı bir iş yapılamıyorsa uzaktan kod çalıştırma açıklarını düzeltmeyi reddetme eğiliminde oluyor. Böylece sandbox ana savunma hattı gibi kullanılmaya başlanıyor ve bu üzücü

    • “Sandbox’tan çıkılamıyorsa uzaktan kod çalıştırma açıklarını düzeltmeyi reddederler” derken kimden bahsedildiğini bilmiyorum
      Bildiğim kadarıyla Apple, Microsoft ve Google’ın hepsinin bug bounty programı var; sandbox kaçışlarına daha yüksek ödül veriyorlar ama sandbox tarafından engellenen açıklar için de yine ödül ödüyorlar
      Herkes, saldırganların şu an kullanamayacakları uzaktan kod çalıştırma açıklarını bir kenarda tutup bir sandbox kaçışı bulunduğunda bunları birlikte kullanabileceklerinin farkında

  • Konudan biraz sapıyor ama sandbox konusunda uzman olup da maximum "pattern serialization length" sınırını aşma stratejisini bilen biri varsa, bu mesele yüzünden epey uzun süre başım ağrıdı: https://github.com/NixOS/nix/issues/4119
    Ne yazık ki sandbox-exec neredeyse hiç belgelenmemiş ve ayrıca kaldırılacağı da söyleniyor; bu yüzden çözmesi oldukça can sıkıcı

  • macOS’ta atlatma yöntemleri bitmek bilmiyor. Çünkü bu işletim sistemi baştan böyle ince taneli yetkiler için tasarlanmadı
    Eski Mac OS ve NeXTSTEP teknolojilerinin üstüne sonradan öylece eklenebilecek bir şey değil
    Ben bir güvenlik araştırmacısı değilim, sadece eski bir uygulama geliştiricisiyim; buna rağmen bizzat birkaç atlatma yöntemi buldum. Yani tabiri caizse cesetlerin nereye gömüldüğünü biliyorum
    Ama sonunda aramayı bıraktım. Apple’ın güvenlik açığı bildirim sistemi tam bir felaket ve sanki tek ilgilendikleri şey her şeyi olabildiğince uzun süre gizli tutmakmış gibi geldi. Zaman kaybı
    Genel olarak macOS, göstermelik güvenliğin kurbanı olmuş gibi duruyor. Zayıflamış yazılımlar ve bitmek bilmeyen izin istekleriyle hem kullanıcılara hem de meşru geliştiricilere zarar verirken, gerçek saldırganlar istediklerinde bunu kolayca aşabiliyor. Eski Apple Windows Vista parodilerini hatırlatıyor

    • Bu yazıyı yazan araştırmacı, epey çok açığın yamalanmasını ve bunun için isim verilmesini sağlamayı başarmış gibi görünüyor. Yalnız bu CVE’lerin bazıları birkaç yıllık gibi duruyor
      Şirketin hataları düzeltmek için mümkün olduğunca fazla zaman istemesi de oyunun bir parçası. Başka şirketler, keşfedilen açıkların olabildiğince hızlı duyurulmasını gerçekten ister mi? Kullanıcıların ne kadar hızlı yükselteceğini kontrol edemeyeceklerine göre, duyuruyu geciktirmek son kullanıcı açısından her zaman daha iyidir ve bu, araştırmacının tanıtım isteğinin önüne geçmelidir
      Apple sandbox mimarisi normalde oldukça iyi tasarlanmış görünüyor. Bu olayda sorun sanki mimaride ya da iletişimde bir yerde çıkmış
      Atlatmaların var olması biraz da masaüstü işletim sistemlerinden çok fazla şey beklenmesinden kaynaklanıyor. Masaüstü işletim sistemleri, sunucu platformlarından çok daha incelikli ve karmaşık sistemler olarak görülebilir. Web tarayıcılarında da çok CVE olmasının nedeni aynı. Hem güvenlik hem işlevsellik istiyoruz; bu yüzden ikisinin çakıştığı ara noktanın ortaya çıkması kaçınılmaz
    • “Eski Mac OS ve NeXTSTEP teknolojilerinin üstüne sonradan öylece eklenebilecek bir şey değil” denmesine rağmen, Apple tüm yığını sahip olduğu için bunu yapabiliyor ve gerçekten de yaptı
      Son 20 yılda macOS yazılımını ve donanımını kademeli olarak sertleştirmiş olması bunun kanıtı
      Son kullanıcıların çoğunun fark etmeyeceği kadar kademeliydi ama macOS geliştiricileri, hem büyük hem küçük güncellemelerde uğraşmak zorunda kaldıkları güvenlik kaynaklı sorunları çok iyi biliyor. Örneğin:
      https://eclecticlight.co/2024/08/…
      https://eclecticlight.co/2024/08/…
      https://eclecticlight.co/2024/08/…
      https://eclecticlight.co/2024/09/…
    • Bu tür legacy yükü tüm ana akım işletim sistemlerinde var gibi görünüyor
      Capability tabanlı sistemler var ama gerçekten yaygın kullanılan bir örnek yok
      Çözümün ne olduğunu bilmiyorum. Yine de güvenliği sonradan eklemeye çalışmak, hiçbir şey yapmayıp tek bir uygulama açığının doğrudan tüm kullanıcı hesabının ele geçirilmesine yol açmasından daha iyi görünüyor
    • “Eski Mac OS üstüne sonradan eklenemez” deniyorsa, SELinux bunu başardıysa macOS’u temelden engelleyen şey ne?
    • Bu kısıtlamaların nedeni, üçüncü taraf geliştiricilerin Apple ürünleriyle rekabet etmesini zorlaştırmak

  • pid alanında gözden kaçmış XPC servisleri, macOS sandbox kısıtlarını aşmanın akıllıca bir yolu
    Yetki kontrollerini atlayan dyld enjeksiyon numarası da çok temiz
    Apple’ın yaması burada geçici bir çözüm gibi hissettiriyor; belki de sandbox kalıtımının çalışma biçimini gerçekten elden geçirmek gerekiyor